Date: 2020-110
CEN/TC 434
Secretariat:
Electronic Invoicing — Part 1: Semantic Data Model of the Core Elements of an Electronic Invoice
Einführendes Element — Haupt-Element — Teil 1: Teil-Titel
Élément introductif — Élément central — Partie 1 : Titre de la partie
ICS: 35.240.20 ; 35.240.60
Descriptors:
Contents Page
4 The concept of a core invoice 10
4.1 The core invoice model as a response to the challenge of interoperability 10
4.2 Contents of the core invoice model 11
4.3 How to use and extend the core invoice model 12
4.4.2 Compliance of the core invoice usage specifications 13
4.4.3 Compliance of sending or receiving party 14
4.4.4 Compliance of an invoice document instance 14
5 Business processes and functionality supported by the core invoice 14
5.1 The business parties involved and their roles and relationships 14
5.2 Business process requirements supported 15
5.2.2 Invoicing of deliveries against purchase orders, based on a contract (P1) 17
5.2.3 Periodic invoicing of deliveries based on a contract, where no purchase order is required (P2) 18
5.2.4 Invoicing the delivery against an incidental purchase order (P3) 18
5.2.7 Payment in advance of delivery, based on a purchase order (P6) 21
5.2.8 Invoices with references to a despatch advice (P7) 21
5.2.9 Invoices with references to a despatch advice and a receiving advice (P8) 22
5.2.10 Credit Note or negative invoicing (P9) 22
5.2.11 Corrective invoicing (P10) 23
5.2.12 Partial and final invoicing (P11) 24
5.3 Invoicing functionality supported 25
5.4 The core invoice model in relation to other documents in the procurement process 33
6 The semantic data model of the core elements of an electronic invoice and credit note 34
6.2 The core invoice model - Legend 36
6.4.1 Integrity constraints 70
6.5.3 Unit Price Amount. Type 90
6.5.7 Document Reference. Type 91
7 Core Invoice Usage Specification 94
7.3 What may be specified in a CIUS 95
7.3.2 Allowed specifications in a CIUS 96
7.4 Documentation of core invoice usage specifications 97
7.6 Identification of core invoice usage specifications 98
Annex A (informative) Examples 99
A.1.2 Example 1 (Different Invoiced item VAT rates) 99
A.1.3 Example 2 (Item price base quantity) 101
A.1.4 Example 3 (Invoiced quantity unit of measure) 103
A.1.5 Example 4 (Discounts, allowances and charges) 104
A.1.6 Example 5 (Negative Invoice line) 107
A.1.7 Example 6 (Prepayment and negative Amount due for payment) 109
A.1.8 Example 7 (Standard VAT including VAT exempted lines) 110
A.1.9 Example 8 (Reverse Charge, Intra EU supply and Export Invoices) 112
A.2 Number of decimals and rounding 113
A.3.1 Taxes other than VAT 114
A.3.2 Allowances and charges 117
A.3.4 Payment instructions 123
Annex B (informative) Assessment of the compliance of the European Standard with the requirements of the Standardization Request of the European Commission 127
B.2 Sections of the invoice 127
B.3 How requirements in the Standardization Request are met in EN 16931‑1 128
B.3.2 Specific business requirements 130
B.3.3 ESO (European Standardization Organization- CEN) requirements 138
B.4 Guide to indicators for relevance and risk as used in the above tables 140
Annex C (informative) How the semantic model meets legal requirements from relevant directives 141
Annex D (informative) BPMN symbols 146
This document (EN 16931‑1:2017) has been prepared by Technical Committee CEN/TC “Electronic Invoicing”, the secretariat of which is held by NEN.
This European Standard shall be given the status of a national standard, either by publication of an identical text or by endorsement, at the latest by December 2017, and conflicting national standards shall be withdrawn at the latest by December 2017.
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. CEN shall not be held responsible for identifying any or all such patent rights.
This document has been prepared under a mandate given to CEN by the European Commission and the European Free Trade Association, and supports essential requirements of EU Directive 2014/55/EU [1].
For relationship with EU Directive 2014/55/EU [1], see informative Annex B, which is an integral part of this document.
This document is part of a set of documents, consisting of:
— EN 16931‑1:2017 Electronic invoicing - Part 1: Semantic data model of the core elements of an electronic invoice
— CEN/TS 16931-2:2017 Electronic invoicing - Part 2: List of syntaxes that comply with EN 16931-1
— CEN/TS 16931-3-1:2017 Electronic invoicing - Part 3-1: Methodology for syntax bindings of the core elements of an electronic invoice
— CEN/TS 16931-3-2:2017 Electronic invoicing - Part 3-2: Syntax binding for ISO/IEC 19845 (UBL 2.1) invoice and credit note
— CEN/TS 16931-3-3:2017 Electronic invoicing - Part 3-3: Syntax binding for UN/CEFACT XML Cross Industry Invoice D16B
— CEN/TS 16931-3-4:2017 Electronic invoicing - Part 3-4: Syntax binding for UN/EDIFACT INVOIC D16B
— CEN/TR 16931-4:2017 Electronic invoicing - Part 4: Guidelines on interoperability of electronic invoices at the transmission level
— CEN/TR 16931-5:2017 Electronic invoicing - Part 5: Guidelines on the use of sector or country extensions in conjunction with EN 16931-1, methodology to be applied in the real environment
According to the CEN-CENELEC Internal Regulations, the national standards organizations of the following countries are bound to implement this European Standard: Austria, Belgium, Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia, Finland, Former Yugoslav Republic of Macedonia, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland, Turkey and the United Kingdom.
To achieve this goal, Directive 2014/55/EU [1] on electronic invoicing in public procurement aims at facilitating the use of electronic invoices by economic operators when supplying goods, works and services to the public administration. The Directive sets out the legal framework for the establishment and use of a European Standard (EN) for the semantic data model of the core elements of an electronic invoice.
The semantic data model of the core elements of an electronic invoice – the core invoice model – as described in this document is based on the proposition that a quite limited, but sufficient set of information elements can be defined that supports generally applicable invoice-related functionalities. These functionalities are described in Clause 5. The core invoice model, as described in Clause 6, contains information elements that are commonly used and accepted including those that are legally required.
It is expected that in most situations, business partners would use the core invoice model exclusively and the invoices they send or receive would not contain any additional structured information elements. However, in some sectors or situations where there are specific information requirements, the required information may be conveyed in the form of unstructured text. Unstructured text has the drawback in that it cannot be processed automatically and therefore requires human intervention. Alternatively, the specific information requirements can be implemented using information elements that extend the core invoice model. Any such extension needs to respect the semantic definitions in the core invoice model. Only business partners that are part of such a sector or supply chain would be expected to be able to process the extensions. In these circumstances, it should be possible to define a number of required additional information elements whilst still utilizing the core invoice model concept.
In line with Directive 2014/55/EU [1] and after the publication of the reference to this document in the Official Journal of the European Union, all contracting authorities and contracting entities in the EU will be obliged to be able to receive and process an e-invoice as long as it contains all of the (applicable) core elements of an invoice defined in this European Standard (and provided that it is represented in any of the syntaxes identified in the related Technical Specification CEN/TS 16931-2 “List of syntaxes that comply with EN 16931-1” in accordance with the request referred to in paragraph 1 of article 3 of the Directive 2014/55/EU. The inclusion of any additional information which is not contained in the core model will be at the sender’s discretion and contained in unstructured text or in an extension, by agreement with the contracting entity. The inclusion of any extension in an e-invoice will be optional, and it will not form an integral part of the European Standard. See Clause 4 below for further detail on extensions.
By ensuring semantic interoperability of electronic invoices, the European Standard and its ancillary European standardization deliverables will serve to remove market barriers and obstacles to trade deriving from the existence of various national rules and standards – and thus contribute to the goals set by the European Commission.
This European Standard establishes a semantic data model of the core elements of an electronic invoice. The semantic model includes only the essential information elements that an electronic invoice needs to ensure legal (including fiscal) compliance and to enable interoperability for cross-border, cross sector and for domestic trade. The semantic model may be used by organizations in the private and the public sector for public procurement invoicing. It may also be used for invoicing between private sector enterprises. It has not been specifically designed for invoicing consumers.
This European Standard complies at least with the following criteria:
— it is technologically neutral;
— it is compatible with relevant international standards on electronic invoicing;
— the application of this standard should comply with the requirements for the protection of personal data of Directive 95/46/EC, having due regard to the principles of privacy and data protection by-design, data minimization, purpose limitation, necessity and proportionality;
— it is consistent with the relevant provisions of Directive 2006/112/EC [2];
— it allows for the establishment of practical, user-friendly, flexible and cost-efficient electronic invoicing systems;
— it takes into account the special needs of small and medium-sized enterprises as well as of sub-central contracting authorities and contracting entities;
— it is suitable for use in commercial transactions between enterprises.
The following documents, in whole or in part, are normatively referenced in this document and are indispensable for its application. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies.
EN ISO 3166‑1, Codes for the representation of names of countries and their subdivisions — Part 1: Country codes (ISO 3166-1)
ISO 4217, Codes for the representation of currencies
ISO 8601, Data elements and interchange formats — Information interchange — Representation of dates and times
ISO 15000‑5, Electronic Business Extensible Markup Language (ebXML) — Part 5: Core Components Specification (CCS)
ISO/IEC 6523 (all parts), Information technology — Structure for the identification of organizations and organization parts
For the purposes of this document, the following terms and definitions apply.
NOTEBusiness terms that are part of the semantic model are defined in the model itself.
3.1
electronic invoice
invoice that has been issued, transmitted and received in a structured electronic format which allows for its automatic and electronic processing
[SOURCE: Directive 2014/55/EU [1]]
3.2
semantic data model
structured set of logically interrelated information elements
3.3
information element
semantic concept that can be defined independent of any particular representation in a syntax
3.4
structured information element
information element that can be processed automatically
3.5
syntax
machine-readable language or dialect used to represent the information elements contained in an electronic document (e.g. an electronic invoice)
3.6
business term
label assigned to a given information element which is used as a primary reference
3.7
core invoice model
semantic data model of the core elements of an electronic invoice
3.8
core elements of an electronic invoice
set of essential information elements that an electronic invoice may contain in order to enable cross-border interoperability, including the necessary information to ensure legal compliance
3.9
identifier
character string used to establish the identity of, and distinguish uniquely, one instance of an object within an identification scheme from all other objects within the same scheme
Note 1 to entry:An identifier may be a word, number, letter, symbol, or any combination of those, depending on the identification scheme used.
3.10
identification scheme
collection of identifiers applicable for a given type of object governed under a common set of rules
3.11
compliant
some or all features of the core invoice model are used and all rules of the core invoice model are respected
Note 1 to entry: Based on TOGAF definition of a compliant specification [18].
3.12
conformant
all rules of the core invoice model are respected and some additional features not defined in the core invoice model are also used
Note 1 to entry: Based on TOGAF definition of a conformant specification [18].
The establishment of interoperability of business information systems with respect to the exchange of electronic documents such as invoices is viewed by many as a major challenge for the following reasons:
a)the overall business environment is very diverse and consequently so is the information that needs to be exchanged between business partners;
b)documents such as invoices consist of many information elements; attempting to define and standardize all occurring information elements would generate a very large and complex information model that no single organization could implement entirely;
c)even if a complete implementation of such a large model were possible, its implementation across the business environment would be very challenging and costly;
d)as experience shows, business partners in various industry sectors will agree on subsets of the model that are supported by their business information systems. Such variety would work against the principles of using common standards, jeopardize interoperability and result in expensive implementation projects.
This document is based on a different approach. In contrast to collecting and meeting the requirements of all businesses, a semantic model is defined that includes only the essential information elements that an electronic invoice needs to ensure legal (including fiscal) compliance and to enable interoperability for cross-border, cross-sector and domestic trade. The semantic model may be used by public and private sector organizations for public procurement invoicing. It may also be used for invoicing between private sector enterprises.
The result of this approach is a semantic model of core information elements for an electronic invoice, i.e. a core invoice model. The following guiding principles form the basis of the core invoice model:
1)it should be easier to prepare and send, as well as to receive and process electronic invoices when compared to paper invoices;
2)the use of standardized information elements should make electronic invoice processing more efficient than processing paper invoices;
3)compliance with the core invoice model should mean that business partners should be able to interpret and understand the content of an electronic invoice at the semantic level without prior consultation or bilateral agreements;
4)invoices should be composed of structured information elements to enable efficient and automatic processing;
5)invoice processing software should be able to present all information elements in the core invoice model, and automatically process all structured data;
6)the use of structured data should result in optimized business processes;
7)the core invoice model makes no assumption about the method by which an invoice is created, delivered and processed. It may be exchanged directly between business partners or exchanged using an intermediary service provider;
8) the core invoice model makes no assumption about the syntax or transmission technology used. Senders and receivers of e-invoices shall ensure the authenticity and integrity of the invoice according to relevant regulations. Mapping to several syntaxes is provided in CEN/TS 16931-3 from subpart 2 onward.
The core invoice model is based on the proposition that a quite limited, but nevertheless consists of a sufficient set of information elements which can be defined and support generally applicable invoice-related functionalities. These functionalities include invoice issuance and delivery, invoice validation, accounting, VAT reporting, payment and auditing. The core invoice model contains information elements that are commonly used and accepted, including those that are legally required.
If all organisations in Europe were to implement the core invoice model in their business information systems using the specified information elements, then sending, receiving and processing invoices electronically, without human intervention, would be possible. There would be no need for onerous pre-negotiated bilateral agreements between organizations on the actual semantic content of the invoice and its exchange. The only assumption is the existence of a normal business contract or trading agreement. The core invoice model supports a set of invoice functions, as specified in Clause 5 below.
The set of information elements that are contained in the core invoice model is commonly considered to consist of two parts: a legal part and a common part.
The legal part of the core invoice model supports the observance of both tax and commercial legal and regulatory requirements pertaining to electronic invoicing commonly in force throughout the EU.
The common part contains commonly used and accepted information elements that are not sector or country specific.
A specific information element may be correctly allocated to one or both parts. Therefore categorizing elements with respect to these parts in the semantic model is not considered to be meaningful.
To fulfil the requirements above, judgment has had to be made on the selection of the information elements to be included in the core invoice model. First, for the legal part requirements, the selection has been made regarding the information elements required on a mandatory basis by EU VAT Directives and individual state law, whether local VAT regulations, or any other local legal provision (regulatory, contractual company law, laws on business documents, etc.). In some cases, those information elements that are exclusively confined to a single or very small number of countries and therefore fall outside the doctrine of ‘commonly in force throughout the EU’ have not been included in the core invoice model. Secondly, the elements selected to satisfy the requirements of the common part form a justifiable selection of requirements required in commercial practice.
As stated in the previous subclause, the core invoice model is intended to be used for all generally applicable invoicing processes. In most situations, business partners would use the core invoice model exclusively and the invoices they send or receive would contain only structured information elements defined in the model. Where a dedicated field exists for a business term or piece of data, this field shall be used for the information content instead of using a textual field.
There are however circumstances where the trading partners may wish to: Either 1. restrict the information elements to be used in an e-invoice or 2. to provide additional information elements. The first requirement is satisfied using a Core Invoice Usage Specification (CIUS). The second requirement is satisfied using an extension specified in an Extension Specification.
In many trading situations, it may be appropriate to restrict the use of conditional information elements present in the core invoice model in some way to support automated processing. The use of a CIUS to specify these requirements is described in Clause 7 below. The CIUS is a specification that provides a seller with detailed guidance, explanations and examples, relating to the actual implementation and use of the information elements in the core invoice model in a specific trading situation.
Typically, a CIUS will be created by a contracting entity (buyer) in relation to its own supply chain or by a group of contracting entities wishing to achieve consistency in the way that the information elements in the core invoice model are to be used by sellers trading with an identified sector or community of buyers. The requirements set out in such a CIUS will be communicated to sellers or placed on a website, and may be included in the contractual documentation between the parties. Alternatively, a CIUS may be created by a group of sellers and agreed in turn by their buyer or buyers in the context of a specific industry or supply chain.
A CIUS is a set of usage guidelines or restrictions made to the core invoice model that will still produce an invoice instance that is fully compliant with the core invoice model set out in this document. That means that a receiver of an invoice document instance that has been created in compliance with a CIUS is still able to receive and process it in accordance with the rules defined for the core invoice model.
In some sectors or situations where there are specific additional information requirements, the required information may be conveyed in the form of unstructured text. Unstructured text has the drawback in that it cannot be processed automatically and therefore requires human intervention.
Alternatively, the specific information requirements can be implemented using an extension containing information elements that extend the core invoice model (See CEN/TR 16931-5 for the methodology applicable to the use of extensions). Any such extension shall not infringe or contradict the semantic definitions in the core invoice model. Only business partners that are part of such a sector or supply chain would be expected to be able to process the extensions. In these circumstances, it is possible to carefully define the required additional information elements, whilst still utilizing the core invoice model concept.
Some extensions are not specific to a single supply chain or industry sector, but may be specific to functions or business processes required by more than one sector. E.g. the vendor managed inventory (VMI) process has been implemented by, for example, the automotive, steel and printing industries. The VMI business process may require additional information elements, not present in the core invoice model. Clearly, similar functions and processes should consistently use the same information elements across Europe.
The development of sector specific or cross-sector extensions should be based on justified business requirements. These can only be gathered by industry experts, (private and public) sector organizations and their customers, who understand those requirements. The semantic model of these additional information elements will need to be defined and registered as an extension with the appropriate organization.
Compliance to the core invoice model, can be measured at three levels:
— at the level of specifications;
— the actual implementation of a given sender or receiver; and
— the individual invoice instance documents.
Each of these levels is discussed in 4.4.2 to 4.4.4.
The core invoice usage specifications that are used in conjunction with the core invoice model shall themselves comply to the methodology and rules described in this guideline and expressed in the following criteria:
— the specification shall clearly state what business functions and/or legal requirements it is intended to support;
— the specification shall clearly state its issuer and responsible 'governor';
— the specification shall clearly state in what way the requirements of the CIUS differ from the core invoice model, either by documenting the difference only or by specifically pointing out what the differences are;
— the resulting invoice document instance shall be fully compliant to the core invoice model.
— the specification and, when relevant, its version shall be uniquely identifiable both for referencing and for identification in processing;
— the specification shall state its underlying specifications (the core invoice model as well as other specifications that it may build upon);
— the syntax binding of a specification shall follow the syntax binding methodology defined in CEN/TS 16931-3-1.
A receiving party may only claim compliance to the core invoice model if he accepts invoices that comply with the core invoice model in general, or with a CIUS, that is itself compliant with the core invoice model.
A sending party may claim compliance if he sends invoices that comply to the core invoice model, including those issued in accordance with a conformant CIUS.
An invoice document instance is compliant to the core invoice model if it respects all rules defined for the core invoice model, which may include the specification contained in a conformant CIUS.
If an invoice instance document supports requirements that can be considered as a use of a CIUS, the invoice instance document is still compliant to the core invoice model. These invoice instance documents can still be received and processed by a party who is not supporting the CIUS because it still complies to the rules of the core invoice model.
In the basic purchase-to-pay process there are two business parties, the Customer and the Supplier. Each party may fulfil two or three roles in the process. The Customer party has the role of the Buyer (the commercial role that contracts with a Seller and orders the goods and services) and the Receiver (the operational role that receives the goods and services). The Supplier party has the role of the Seller (the commercial role that is contracted by a Buyer) and the Payee (the role that receives the payment). Both parties are considered to be Taxable persons (the role that declares and pays or reclaims VAT), except for some public entities. The Supplier may delegate the operational aspects of that role to a Tax representative, who declares and pays VAT on his behalf.
In the core invoice model, it is assumed that the Supplier party combines, by default, the roles of Seller and Payee. Roles may however be outsourced. The role of Payee may be fulfilled by another party, e.g. a factoring service. The same applies to the roles of the Customer (Buyer and Receiver) that may be fulfilled by different parties. It is assumed that the Seller issues the invoice. Note that in certain transactions the Buyer may be liable to pay VAT instead of the Seller.
An invoice consists of a header and one or more line items. All information about the parties is defined at header level.
Table 1 illustrates the different roles in an invoice:
Context | Role | Explanation |
Supplier: | ||
Trade | Seller (invoice issuer) | Principal role |
Payment | Payee | Additional role, may be a different party from the Seller (e.g. a factoring service) |
Tax | Taxable Person (may engage a Tax representative) | Designation for tax purposes |
Customer: | ||
Trade | Buyer (invoice receiver) | Principal role |
Delivery | Receiver | Additional role, may be a different party from the Buyer (e.g. a subsidiary of the Buyer in another location) |
Tax | Taxable Person | Designation for tax purposes |
Other parties may also play roles in the invoicing process, such as (e.g. transport) service providers and (e.g. tax) authorities. They are however indirectly involved as an agent or counterpart and not included in the table.
The core invoice model supports a basic purchase-to-pay process. Purchase-to-pay processes can be complex due to logistics, legal, product and technical requirements. Examples of such complex processes are: vendor managed inventory, invoicing on behalf of multiple parties in the same invoice, invoicing complex products or project-related products, or ‘swap’ deals. These processes are out of scope of the core invoice model. However, the core invoice model can be extended to support such processes. The extension methodology is described in CEN/TR 16931-5.
This subclause 5.2 describes the processes that are supported by the core invoice model. These processes include buying, selling, delivering goods and services and payment between Customers and Suppliers and their respective roles. How the invoice and other documents are electronically exchanged is not described in the process models. Parties may handle document exchange with their own resources or outsource (part of) it. See also CEN/TR 16931-4.
The process models focus on the external activities of the parties and do not describe internal activities. Only the activities of the roles listed in Table 1 are modelled, not those of third parties.
The process model diagrams are presented in the Business Process Model and Notation (BPMN) of the Object Management Group (OMG) [12]. A short legend of the symbols used can be found in Annex D.
The process models included in 5.2 are intended to indicate the business contexts that are supported by the core invoice model. The models do not give a full definition of those processes.
The core invoice model shall include elements that allow the trading parties to represent any invoice transaction according to the EU VAT directives and should support the following types of business processes:
— P1: Invoicing of deliveries of goods and services against purchase orders, based on a contract;
— P2: Invoicing deliveries of goods and services based on a contract;
— P3: Invoicing the delivery of an incidental purchase order;
— P4: Pre-payment;
— P5: Spot payment;
— P6: Payment in advance of delivery;
— P7: Invoices with references to a despatch advice;
— P8: Invoices with references to a despatch advice and a receiving advice;
— P9: Credit notes or invoices with negative amounts, issued for a variety of reasons including the return of empty packaging;
— P10: Corrective invoicing (cancellation/correction of an invoice);
— P11: Partial and final invoicing;
— P12: Self billing.
Other processes are not explicitly supported, but the core invoice model may still be applicable. In more complex or advanced processes, however, extensions to the information content of the core invoice model may be needed (see CEN/TR 16931-5).
In a number of national and legal environments, descriptions of products, names and addresses of parties, and locations are obligatory in the electronic messages. Therefore, textual representation of these objects is included in the core invoice model. In other jurisdictions, the Buyer and the Seller may agree on one or more identification schemes for products, locations, parties and other objects. These schemes remove the need for textual based descriptions and names and addresses of the objects identified. These schemes are usual agreed in advance of the Purchase to Pay process and there are various mechanism used for this. This process is called Master Data Synchronisation. In the core invoice model it is assumed that a Master Data Synchronisation process has not been implemented.
In this process the contract directly triggers the delivery. There is no requirement for a purchase order. This scenario is common in the delivery of utilities, but also in delivery of, e.g. food services to offices, schools and hospitals. Invoices are issued to cover a fixed period of time (which can be different per invoice line) and there are continuously instances of the goods and service being delivered. An invoice may only refer to one contract.
A Purchase Order is exchanged between the Buyer and the Seller, but it is agreed that invoicing and payment are made in advance of delivery. An invoice may only refer to one purchase order.
On the basis of a commercial agreement the Seller may apply a quarterly or yearly reimbursement (not shown in the diagram). A credit note may also be used in such case.
Many cases exist where an invoice is disputed and/or may need to be corrected. Product descriptions may be wrong, invoiced quantities may differ from delivered quantities, VAT rates may have changed, etc.
A disputed invoice may be corrected by means of the following mechanisms:
1.the disputed invoice may be replaced completely by first sending an identical credit note or an invoice in which the quantities and thus the line and total amounts have been made negative and then sending the correct invoice
2.alternatively an invoice, credit note or negative invoice may be sent with the difference in quantities and amounts between the correct invoice and the disputed invoice. Such a differential corrective invoice or credit note may contain lines that completely compensate lines in the disputed invoice with the corrected lines.
Corrective invoices and credit notes shall refer to the original invoice.
See Annex A for examples of these correction mechanisms.
In some industries, such as Construction and Utilities, during the period of delivery one or more partial invoices are sent before the final invoice. Partial invoices may be estimates of consumption or requests for pre-payment. In some cases, the pre-payment requests do not state the VAT amounts; those are then only stated on the final invoice.
The final invoice shall refer to the partial invoices.
Note that partial invoices without VAT are not allowed in some member states.
In a self-billing process, the Buyer sends the invoice to the Seller. Both Buyer and Seller keep their responsibilities, so the invoice is still issued on behalf of the Seller. According to directive 2006/112/EC, the invoice shall be labelled as being a self-billed invoice and the requirements mentioned in article 224 of this directive shall be met. Self-billing may be introduced only if there is a prior agreement between the two parties and provided that a procedure exists for the acceptance of each invoice by the taxable person supplying the goods or services.
In case of self-billing, the Invoice type code shall be Self-billed invoice or Self-billed credit note. In this case the buyer will have legal responsibility for the invoice.
An invoice may support functions related to a number of related (internal) business processes. The core invoice model shall support the following functions:
— Accounting;
— Invoice verification against the contract, the purchase order and the goods and service delivered;
— VAT reporting;
— Auditing;
— Payment.
In this subclause 5.3, an assessment is made of what information is needed for each of the functions listed above and whether it is in scope or out of scope for the core invoice model. Functions that are in scope and thus are supported by the model have been assigned an identifier (e.g. R1) and have been given a description.
Explicit support for the following functions (but not limited to) is out of scope for the core invoice model although information elements in the core invoice model may provide some support for these functions:
— Inventory management;
— Delivery processes;
— Customs clearance;
— Marketing;
— Reporting.
The requirement identifiers are not necessarily consecutive or in sequence.
Recording a business transaction into the financial accounts of an organization is one of the main objectives of the invoice. According to financial accounting best practice and VAT rules every Taxable person shall keep accounts in sufficient detail for VAT to be applied and its application checked by the tax authorities. For that reason, an invoice shall provide for the information at document and line level that enables booking on both the debit and the credit side.
In scope for the core invoice model:
R1 | information at document level that enables the identification of the Payee, if different from the Seller (all processes, except P9); |
R2 | information at document level that enables booking on both the debit and the credit side (all processes); |
R3 | information at invoice line level that enables booking on the debit side (all processes); |
R4 | Buyer-specific booking information (account numbers) (all processes). |
Out of scope for the core invoice model:
— invoice sub-lines;
— booking information at sub-line level.
This process forms part of the Buyer’s internal business controls. The invoice shall refer to an authentic commercial transaction. Support for invoice verification is a key function of an invoice. The invoice should provide sufficient information to look up relevant existing documentation, electronic or paper, for example, and as applicable to the models detailed above:
— the relevant purchase order;
— the contract;
— the call for tenders, that was the basis for the contract;
— the Buyer’s reference;
— the confirmed receipt of the goods or services.
An invoice should also contain sufficient information that allows the received invoice to be transferred to a responsible authority, person or department, for verification and approval.
In scope for the core invoice model:
R5 | information to trace to a single [ANNOTATION: BY 'Fred van Blommestein' ON '2020-11-09T18:08:00'FvB NOTE: '#50']related purchase orders from the document level (all processes, except P2 and P5); |
R6 | information to trace to a single related purchase order line from the invoice line (all processes, except P2 and P5); |
R7 | information to trace to a single contract and the underlying call for tenders from the document level (all processes, except P3 and P5); |
R8 | a reference supplied by the Buyer at document level (all processes); |
R9 | information to trace to a single [ANNOTATION: BY 'Fred van Blommestein' ON '2020-11-09T18:09:00'FvB NOTE: '#49']multiple despatch advices from the document level (processes P7 and P8); |
R10 | information to trace to a single [ANNOTATION: BY 'Fred van Blommestein' ON '2020-11-09T18:10:00'FvB NOTE: '#49']multiple receiving advices from the document level (process P8); |
R11 | information to trace to a related invoice to be corrected from the document level (process P10); |
R12 | reference to multiple part-invoices from a final invoice (process P12); |
R13 | information to allow an invoice and related documents to be transferred to a responsible authority, entity, person or department, for verification and approval (all processes); |
R14 | information about net price and the quantity on which the price is based at invoice line level, additional information such as gross price and price discount may be added (all processes); |
R15 | descriptive and coded information about allowances and charges at both document level and at invoice line level (all processes); |
R16 | information about charges, (non-VAT-)taxes, duties and levies, with their VAT information, that are not included in the line amounts at document level (all processes); |
R17 | information about charges, (non-VAT-)taxes, duties and levies that compose the taxable amount and are not included in the unit price at separate invoice lines, with a proper identification and/or description (all processes); |
R18 | information about charges at invoice line level as part of the line amount (all processes); |
R19 | the amounts of allowances and charges at document and invoice line level (all processes); |
R20 | textual descriptions of invoiced goods and services at invoice line level (all processes); |
R21 | identification of invoiced goods and services by means of a Seller's item number at invoice line level (all processes); |
R22 | identification of invoiced goods and services by means of a Buyer's item number at invoice line level (all processes); |
R23 | identification of invoiced goods and services by means of a qualified general item identifier at invoice line level as agreed by the Buyer and the Seller (all processes); |
R24 | classification of invoiced goods and services by means of applicable classification identifiers and schema reference as agreed between the Seller and the Buyer at invoice line level (all processes); |
R25 | information about returned and credited returnable assets or packages, such as pallets, and package charges, stated as normal invoice lines (all processes); |
R26 | information about returnable asset charges, stated as normal invoice lines (all processes); |
R27 | information about returned goods, stated as normal invoice lines (all processes); |
R28 | descriptive information about attributes of goods and services at invoice line level (all processes); |
R29 | information about the country of origin of goods and services at invoice line level (all processes); |
R30 | an invoice line period at invoice line level (process P2, P11); |
R31 | one delivery date at document level (all processes); |
R32 | one delivery location or address at document level (all processes); |
R33 | identification of the invoiced object at document and line level (process P2); |
R34 | a delivery/invoice period at document level (process P2, P11); |
R35 | attached documents of a limited set of file types (all processes); |
R36 | multiple attached or referenced documents at document level (all processes); |
R37 | a VAT category and rate at invoice line level (all processes); |
R38 | VAT totals per category at document level (all processes); |
R39 | a quantity and a net amount (exclusive of VAT) at invoice line level (all processes); |
R40 | all amounts at document and invoice line level that make up the invoice total amount and the amount due for payment (all processes); |
R41 | Reference to a sales order, issued by the Seller at document level (all processes); |
R42 | Allowance/charge percentage and base amount at document and invoice line level (all processes); |
R44 | Information to allow automated validation of a received electronic invoice (all processes). |
Out of scope for the core invoice model:
— reference to one or more related purchase order lines on header level;
— reference to multiple related purchase order lines on line level;
— reference to multiple contracts;
— reference to one or more price lists;
— reference to the exact time of delivery;
— reference to one or more receiving advice lines at invoice line level;
— reference to supporting documents at invoice line level;
— reference to one or more consumption reports or performance records;
— reference to one or more invoices for payment in advance;
— reference to multiple sales orders (issued by the Seller);
— sub-lines of allowances and charges;
— delivered quantities of goods and services if different from invoiced quantities;
— ordered quantities of goods and services if different from invoiced quantities;
— back-ordered quantities of goods and services if different from invoiced quantities;
— coded attributes of goods and services;
— specific coded quality information of goods or services;
— structured metered values;
— lot numbers of goods and services (except in free text);
— serial numbers or other identification numbers (e.g. of the person rendering the services) (except in free text);
The invoice is used to carry VAT related information from the Seller to the Buyer to enable the Buyer and Seller to correctly handle VAT booking and reporting. An invoice should contain sufficient information to enable the Buyer and any auditor to determine whether the invoice is correct from a VAT point of view.
The invoice shall allow the determination of the VAT regime, the calculation and description of the tax, in accordance with the European Directive 2006/112/EC [2] and subsequent amendments. VAT reporting applies to all processes.
In scope for the core invoice model:
R45 | information to determine the requirements of the applicable VAT legislation in force and the calculation and reporting thereof; | |
R46 | information on the date the VAT is liable at document level; | |
R47 | the necessary elements for national legal VAT requirements that apply for invoices issued to national and foreign Buyers, such as the legal registration status of the Seller; | |
R48 | information to support the following VAT use cases: | |
| — | Invoices for supplies for which VAT is charged; |
| — | Invoices for supplies for which VAT is not charged based on an exemption reason; |
| — | Invoices for supplies for which the Seller’s goods and services are exempt from VAT at line level; |
| — | Invoices for supplies that are issued under reverse charge; |
| — | Invoices for exempt intra-community supplies for which an intra-community acquisition has to be done; |
| — | Invoices for supplies outside the scope of the Directive 2006/112/EC [2] (non-VAT invoices); |
R49 | the total VAT amount at document level; | |
R50 | total taxable amount per VAT rate at document level; | |
R51 | any additional information required to support the exemption evidence in case VAT is not charged based on an exemption reason at document and at invoice line level; | |
R52 | the legal registration number and the VAT registration number of the Seller and Buyer and the VAT registration number of the Tax representative of the Supplier; | |
R53 | the official postal address of the Buyer, Seller and Tax representative of the Supplier and their place of business and registered office; | |
R54 | the invoice currency and the VAT accounting currency at document level if different from the invoice currency; | |
R55 | codes for exemption [ANNOTATION: BY 'Fred van Blommestein' ON '2020-11-15T08:39:00'FvB NOTE: '#23']and out of scope reasons at document and invoice line level. | |
Out of scope for the core invoice model:
— refund applications (Directive 2008/9/EC [5]);
— structured information that is commonly provided in page footnote of business documents, such as:
—share Capital Amount of the Seller;
—legal form of the Seller.
Companies audit themselves as means of internal control or they may be audited by external parties as part of a legal obligation. Accounting is a regular, ongoing process whereas an audit is a separate review process to ensure that the accounting has been carried out correctly. The auditing process places certain information requirements on an invoice. These requirements are mainly related to enable verification of authenticity and integrity of the accounting transaction. Auditing requirements apply to all of the above processes.
Invoices, conformant to the core invoice model support the auditing process by providing sufficient information for:
— identification of the relevant Buyer and Seller;
— identification of the products and services traded, including description, value and quantity;
— information for connecting the invoice to its payment;
— information for connecting the invoice to relevant documents such as a contract and a purchase order.
In scope for the core invoice model:
R56 | sufficient information to support the auditing process with regard to: — identification of the invoice; — identification of the date of issue of the invoice; — identification of the products and services traded, including their description, value and quantity; — information for relating the invoice to its settlement; — information for relating the invoice to relevant documents such as a contract, a purchase order and a despatch advice; — information about the reason for invoice correction (process P10); |
R57 | identification of the parties that fulfil the following roles at the invoice level, including their legal name and address: — the Seller (including the Seller's trade name); — the Buyer; — the Deliver to party (if different from the Buyer); — the Payee (if different from the Seller); — the Tax representative of the Supplier; |
Out of scope for the core invoice model:
— identification of:
—the carrier;
—the creditor (if different from Payee);
—the debtor (if different from Buyer);
—the identification of the service or business unit of the Seller, issued by the Buyer;
—subtotals for part of the lines.
An invoice represents a claim for payment. The issuance of an invoice may take place either before or after the payment is carried out. When an invoice is issued before payment it represents a request to the Buyer to pay, in which case the invoice commonly contains information that enables the Buyer, in the role of a debtor, to correctly initiate the transfer of the payment, unless that information is already agreed in prior contracts or by means of payment instructions separately lodged with the Buyer.
If an invoice is issued after payment, such as when the order process included payment instructions or when paying with a credit card, online or telephonic purchases, the invoice may contain information about the payment made in order to facilitate invoice to payment reconciliation on the Buyer side. An invoice may be partially paid before issuing such as when a pre-payment is made to confirm an order.
Invoices, conformant with the core invoice model should identify the means of payment for settlement of the invoice and clearly state what payment amount is requested. They should provide necessary details to support bank transfers in accordance with the Single Euro Payments Area (SEPA) for payments in Euro and the relevant national payment practices for other currencies. Payments by means of Credit Transfer, Direct debit, and Payment Card are in scope for making payments of invoices conformant with the core invoice model.
Payment information is needed in all processes.
In scope for the core invoice model:
R58 | identification of the means of settlement; |
R59 | the requested amount due for payment; |
R60 | the date on which payment is due; |
R61 | necessary details to support bank transfers in accordance with SEPA and national systems; |
R62 | a reference number and any additional reference data to be included in the payment; |
R63 | reference number and any additional reference data to be included in the payment, in order to relate the payment to the invoice; |
R64 | information for relating an invoice to a payment card used for settlement; |
R65 | basic information to support national payment systems for use in domestic trade; |
R66 | information about the amount that was pre-paid; |
R67 | invoices that have a total amount of zero; |
R68 | invoices that have an amount to pay of zero; |
R69 | necessary details to support direct debits. |
R70 | pre-payment invoices |
Out of scope for the core invoice model:
— instalments;
— references to pre-payments;
— early-payment allowances in a structured way;
— late-payment penalty schemes in a structured way;
— quoted or referenced structured payment terms.
Invoices are sometimes used by the Buyer for placing goods into inventory, as replacement of more appropriate documents such as despatch advices or packing lists. Support for inventory management is not in scope of the core invoice model, although it is recognized that information provided for other processes, supported in the core invoice model, may be used for placing goods into inventory.
Out of scope for the core invoice model:
— information to support inventory management.
Invoices may be used by the business partners involved for: order picking, delivery instructions and receipt; as a replacement for more appropriate documents such as: Instructions to despatch, transport documents or packing lists. Specific support for delivery processes is however not in scope for the core invoice model and other appropriate electronic documents should be used.
Out of scope for the core invoice model:
— information to support the delivery process;
— delivery terms.
When goods are cleared through customs, important information about the goods being cleared may be extracted from the invoice. Customs clearing may also require special information such as the origin of the items, materials used and other issues that may affect the classification and the calculation of import duties and taxes. For customs purposes an invoice may also contain the customs classification itself.
The core invoice model is not intended to specifically support customs clearance in general although information provided for other processes supported in the invoice may be used for customs purposes.
Out of scope for the core invoice model:
— specific support for customs clearance.
Invoices may be used to deliver marketing messages to the Buyer in the form of text or as images, but no specific marketing information is within scope of the core invoice model.
Out of scope for the core invoice model:
— specific support for marketing.
Invoices, such as utility invoices, frequently contain detailed information about usage of services that provide a breakdown of the total quantity in the invoice itself. No specific reporting information is within scope of the core invoice model itself but such information can be provided e.g. with attachments.
Out of scope for the core invoice model:
— specific reporting information.
The relationships between the invoice and other documents and events are depicted in Figure 14. The listed documents should be interpreted in the scope of the relevant business processes, modelled in 5.2.
NOTE 1A Purchase order is an object that may be the result of exchanging a number of documents, such as confirmations and purchase order changes.
NOTE 2An invoice does, according to the core invoice model, not refer to each pre-payment event, but merely cites the total pre-paid amount.
This Clause 6 describes the information elements, and groups of information elements, that constitutes the semantic data model of the core elements of an electronic Invoice, as well as their relationship and the business rules required to ensure the integrity and consistency in the data provided in a compliant instance document (an individual Invoice).
For an instance document to be compliant to the core invoice model, it shall respect all rules defined in this Clause 6.
It is the responsibility of the invoice issuer to ensure that an Invoice respects any rules defined by relevant legislation, including requirements related to personal data protection, as well as rules stated as part of a trading relationship between the Seller and the Buyer. An Invoice conforming to the rules of the semantic data model of the core elements of an electronic Invoice as described in this Clause 6 does not guarantee its legal compliance OR compliance to contractual obligations.
An overview of the groups of information elements contained in the semantic model is provided in Figure 15. Each of these groups and their detailed content is explained in detail in 6.2.
The business rules defined in order to ensure the integrity and consistency in the data provided in a compliant instance document can be found in 6.3.
The semantic data type assigned to individual information elements in the core invoice model to specify data format and metadata requirements that apply are detailed in 6.4.
Calculation examples are provided in 6.5.
NOTEThe figure only shows the information element groups. Individual information elements are not shown.
Each information element, as well as groups of information elements, that constitutes the semantic data model of the core elements of an electronic Invoice is described as a row in the table documented in 6.3 where the following information is provided:
ID | Level | Cardinality | Business Term | Description | Usage Note | Req. ID | Semantic data type |
ID: An identifier for the information element (BT - Business Term) and group of information elements (BG - Business terms Group). The identifiers are not necessarily consecutive or in sequence.
Level: Indicates on which level in the model the information element occurs:
— +: The first level of the model;
— ++: The second level of the model. The information element (or the group of information elements) is part of a group of information elements which is defined at the first level of the model;
— +++: The third level of the model. The information element (or the group of information elements) is part of a group of information elements which is defined at the second level of the model;
— ++++: The fourth level of the model. The information element is part of a group of information elements which is defined at the third level of the model.
Cardinality: Also known as multiplicity is used to indicate if an information element (or group of information elements) is mandatory or conditional, and if it is repeatable. The cardinality shall always be analysed in the context of where the information element is used. Example: the Payee Name is mandatory in the core invoice model, but only when a Payee is stated and is relevant.
The following cardinalities exist:
— 1..1: Mandatory, minimum 1 occurrence and maximum 1 occurrence of the information element (or group of information elements) shall be present in any compliant instance document;
— 1..n: Mandatory and repeatable, minimum 1 occurrence and unbounded upper maximum occurrences of the information element (or group of information elements) shall be present in any compliant instance document;
— 0..1: Conditional, minimum 0 occurrences and maximum 1 occurrence of the information element (or group of information elements) may be present in any compliant instance document; it's use depends on business rules stated as well as the regulatory, commercial and contractual conditions that applies to the business transaction;
— 0..n: Conditional and repeatable, minimum 0 occurrences and unbounded upper maximum occurrences of the information element (or group of information elements) may be present in any compliant instance document; it's use depends on business rules stated as well as the regulatory, commercial and contractual conditions that applies to the business transaction.
Business Term: The name of the information element used in the core invoice model or the name of a coherent group of related information elements, provided to give logical meaning.
Description: A description of the semantic meaning of the information element.
Usage Note: Clarifying information on how the information element shall or may be used (such as calculation rules).
Req. ID: The requirement identifier, provided to show the traceability of the information element with the corresponding requirement defined in Clause 5.
Semantic data type: The data format that applies to the information element (see 6.5).
Supplementary components or attributes are specified with the Business Term they belong to.
Note that in the naming of business terms, in descriptions and in usage notes, the term “invoice” also applies to Credit notes, unless mentioned otherwise.
ID | Level | Cardinality | Business Term | Description | Usage Note | Req. ID | Semantic data type3 |
BT-1 | + | 1..1 | Invoice number | A unique identification of the Invoice. | The sequential number required in Article 226(2) of the directive 2006/112/EC [2], to uniquely identify the Invoice within the business context, time-frame, operating systems and records of the Seller. It may be based on one or more series of numbers, which may include alphanumeric characters. No identification scheme is to be used. | R56 | Identifier |
BT-2 | + | 1..1 | Invoice issue date | The date when the Invoice was issued. |
| R56 | Date |
[ANNOTATION: BY 'fred' ON '2020-10-30T11:02:00'f NOTE: '#11']BT-X | + | 0..1 | Invoice issue time | The time of the day when the Invoice was issued. |
|
| Time |
BT-3 | + | 1..1 | Invoice type code | A code specifying the functional type of the Invoice. | Commercial invoices and credit notes are defined according the entries in UNTDID 1001 [6]. Other entries of UNTDID 1001 [6] with specific invoices or credit notes may be used if applicable. | R44 | Code |
BT-5 | + | 1..1 | Invoice currency code | The currency in which all Invoice amounts are given, except for the Total VAT amount in accounting currency. | Only one currency shall be used in the Invoice, except for the Invoice total VAT amount in accounting currency (BT-111) in accordance with article 230 of Directive 2006/112/EC on VAT [2]. The lists of valid currencies are registered with the ISO 4217 Maintenance Agency “Codes for the representation of currencies and funds”. | R54, R47 | Code |
BT-6 | + | 0..1 | VAT accounting currency code | The currency used for VAT accounting and reporting purposes as accepted or required in the country of the Seller. | Shall be used in combination with the Invoice total VAT amount in accounting currency (BT-111) when the VAT accounting currency code differs from the Invoice currency code. The lists of valid currencies are registered with the ISO 4217 Maintenance Agency “Codes for the representation of currencies and funds”. Please refer to Article 230 of the Council Directive 2006/112/EC [2] for more information. | R54 | Code |
BT-7 | + | 0..1 | Value added tax point date | The date when the VAT becomes accountable for the Seller and for the Buyer in so far as that date can be determined and differs from the date of issue of the invoice, according to the VAT directive. | The tax point is usually the date goods were supplied or services completed (the 'basic tax point'). There are some variations. Please refer to Article 226 (7) of the Council Directive 2006/112/EC [2] for more information. This element is required if the Value added tax point date is different from the Invoice issue date. Both Buyer and Seller should use the Tax Point Date when provided by the Seller. The use of BT-7 and BT-8 is mutually exclusive. | R45 R46 | Date |
BT-8 | + | 0..1 | Value added tax point date code | The code of the date when the VAT becomes accountable for the Seller and for the Buyer. | The code shall distinguish between the following entries of UNTDID 2005 [6]: - Invoice document issue date - Delivery date, actual - Paid to dateThe Value added tax point date code is used if the Value added tax point date is not known when the invoice is issued. The use of BT-8 and BT-7 is mutually exclusive. | R45 R46 | Code |
BT-9 | + | 0..1 | Payment due date | The date when the payment is due. | The payment due date reflects the due date of the net payment. For partial payments it states the first net due date. The corresponding description of more complex payment terms can be stated in BT-20 Payment terms. | R60 | Date |
BT-10 | + | 0..1 | Buyer reference | An identifier assigned by the Buyer used for internal routing purposes. | The identifier is defined by the Buyer (e.g. contact ID, department, office id, project code), but provided by the Seller in the Invoice. | R8 | Text |
BT-11 | + | 0..1 | Project reference | The identification of the project the invoice refers to |
| R44 | Document reference |
BT-12 | + | 0..1 | Contract reference | The identification of a contract. | The contract identifier should be unique in the context of the specific trading relationship and for a defined time period. | R7 | Document reference |
BT-13 | + | 0..1 | Purchase order reference | An identifier of a referenced purchase order, issued by the Buyer. |
| R5, R56 | Document reference |
BT-14 | + | 0..1 | Sales order reference | An identifier of a referenced sales order, issued by the Seller. |
| R41 | Document reference |
BT-15 | + | 0..1 | Receiving advice reference | An identifier of a referenced receiving advice. |
| R10, R56 | Document reference |
BT-16 | + | 0..1 | Despatch advice reference | An identifier of a referenced despatch advice. |
| R9, R56 | Document reference |
BT-17 | + | 0..1 | Tender or lot reference | The identification of the call for tender or lot the invoice relates to. | In some countries a reference to the call for tender that has led to the contract shall be provided. | R7, R4 | Document reference |
BT-18 | + | 0..1 | Invoiced object identifier | An identifier for an object on which the invoice is based, given by the Seller. | It may be a subscription number, telephone number, meter point, vehicle, person etc., as applicable. | R33 | Identifier |
|
| 0..1 | Scheme identifier | The identification scheme identifier of the Invoiced object identifier. | If it may be not clear for the receiver what scheme is used for the identifier, a conditional scheme identifier should be used that shall be chosen from the UNTDID 1153 code list [6] entries. |
|
|
BT-19 | + | 0..1 | Buyer accounting reference | A textual value that specifies where to book the relevant data into the Buyer's financial accounts. |
| R2, R4 | Text |
BT-20 | + | 0..1 | Payment terms | A textual description of the payment terms that apply to the amount due for payment (Including description of possible penalties). | This element may contain multiple lines and multiple terms. | R60 | Text |
BG-1 | + | 0..n | INVOICE NOTE | A group of business terms providing textual notes that are relevant for the invoice, together with an indication of the note subject. |
| R56 |
|
BT-21 | ++ | 0..1 | Invoice note subject code | The subject of the textual note in BT-22. | To be chosen from the entries in UNTDID 4451 [6]. | R56 | Text |
BT-22 | ++ | 1..1 | Invoice note | A textual note that gives unstructured information that is relevant to the Invoice as a whole. | Such as the reason for any correction or assignment note in case the invoice has been factored | R56 | Text |
BG-2 | + | 1..1 | PROCESS CONTROL | A group of business terms providing information on the business process and rules applicable to the Invoice document. |
| R44 |
|
BT-23 | ++ | 0..1 | Business process type | Identifies the business process context in which the transaction appears, to enable the Buyer to process the Invoice in an appropriate way. | To be specified by the Buyer.
| R44 | Text |
BT-24 | ++ | 1..1 | Specification identifier | An identification of the specification containing the total set of rules regarding semantic content, cardinalities and business rules to which the data contained in the instance document conforms. | This identifies compliance or conformance to this document. Compliant invoices specify: urn:cen.eu:en16931:2017. Invoices, compliant to a user specification may identify that user specification here. No identification scheme is to be used. | R44 | Identifier |
BG-3 | + | 0..n | PRECEDING INVOICE REFERENCE | A group of business terms providing information on one or more preceding Invoices. | To be used in case: - a preceding invoice is corrected - preceding partial invoices are referred to from a final invoice -preceding pre-payment invoices are referred to from a final invoice | R11 R12 |
|
BT-25 | ++ | 1..1 | Preceding Invoice reference | The identification of an Invoice that was previously sent by the Seller. |
| R11 R12 | Document reference |
BT-26 | ++ | 0..1 | Preceding Invoice issue date | The date when the Preceding Invoice was issued. | The Preceding Invoice issue date shall be provided in case the Preceding Invoice identifier is not unique. | R11 R12 | Date |
BG-4 | + | 1..1 | SELLER | A group of business terms providing information about the Seller. |
| R48 |
|
BT-27 | ++ | 1..1 | Seller name | The full formal name by which the Seller is registered in the national registry of legal entities or as a Taxable person or otherwise trades as a person or persons. |
| R48 | Text |
BT-28 | ++ | 0..1 | Seller trading name | A name by which the Seller is known, other than Seller name (also known as Business name). | This may be used if different from the Seller name. | R48 | Text |
BT-29 | ++ | 0..n | Seller identifier | An identification of the Seller. | For many systems, the Seller identifier is a key piece of information. Multiple Seller identifiers may be assigned or specified. They may be differentiated by using various identification schemes. If no scheme is specified, it should be known by Buyer and Seller, e.g. a previously exchanged Buyer assigned identifier of the Seller. | R57 | Identifier |
|
| 0..1 | Scheme identifier | The identification scheme identifier of the Seller identifier. | If used, the identification scheme identifier shall be chosen from the entries of the list published by the ISO/IEC 6523 maintenance agency. |
|
|
BT-30 | ++ | 0..1 | Seller legal registration identifier | An identifier issued by an official registrar that identifies the Seller as a legal entity or person. | If no identification scheme is specified, it should be known by Buyer and Seller. | R52 | Identifier |
|
| 0..1 | Scheme identifier | The identification scheme identifier of the Seller legal registration identifier. | If used, the identification scheme shall be chosen from the entries of the list published by the ISO/IEC 6523 maintenance agency. |
|
|
BT-31 | ++ | 0..1 | Seller VAT identifier | The Seller's VAT identifier (also known as Seller VAT identification number). | VAT number prefixed by a country code. A VAT registered Supplier shall include his VAT ID, except when he uses a tax representative. | R52 | Identifier |
BT-32 | ++ | 0..1 | Seller tax registration identifier | The local identification (defined by the Seller’s address) of the Seller for tax purposes or a reference that enables the Seller to state his registered tax status. | This information may affect how the Buyer settles the payment (such as for social security fees). E.g. in some countries, if the Seller is not registered as a tax paying entity then the Buyer is required to withhold the amount of the tax and pay it on behalf of the Seller. | R47 | Identifier |
BT-33 | ++ | 0..1 | Seller additional legal information | Additional legal information relevant for the Seller. | Such as share capital. | R47 | Text |
BT-34 | ++ | 0..1 | Seller electronic address | Identifies the Seller's electronic address to which the application level response to the invoice may be delivered. |
| R13, R57 | Identifier |
|
| 1..1 | Scheme identifier | The identification scheme identifier of the Seller electronic address. | The scheme identifier shall be chosen from [ANNOTATION: BY 'fred' ON '2020-10-30T11:02:00'f NOTE: '#24']the EAS (Electronic Address Scheme) lista list to be maintained by the Connecting Europe Facility. |
|
|
BG-5 | ++ | 1..1 | SELLER POSTAL ADDRESS | A group of business terms providing information about the address of the Seller. | Sufficient components of the address are to be filled to comply with legal requirements. | R53 |
|
BT-35 | +++ | 0..1 | Seller address line 1 | The main address line in an address. | Usually the street name and number or post office box. | R53 | Text |
BT-36 | +++ | 0..1 | Seller address line 2 | An additional address line in an address that can be used to give further details supplementing the main line. |
| R53 | Text |
BT-162 | +++ | 0..1 | Seller address line 3 | An additional address line in an address that can be used to give further details supplementing the main line. |
| R53 | Text |
BT-37 | +++ | 0..1 | Seller city | The common name of the city, town or village, where the Seller address is located. |
| R53 | Text |
BT-38 | +++ | 0..1 | Seller post code | The identifier for an addressable group of properties according to the relevant postal service. | Such as a ZIP code or a post code. | R53 | Text |
BT-39 | +++ | 0..1 | Seller country subdivision | The subdivision of a country. | Such as a region, a county, a state, a province, etc. | R53 | Text |
BT-40 | +++ | 1..1 | Seller country code | A code that identifies the country. | If no tax representative is specified, this is the country where VAT is liable. The lists of valid countries are registered with the EN ISO 3166‑1 Maintenance agency, “Codes for the representation of names of countries and their subdivisions”. | R53 | Code |
BG-6 | ++ | 0..1 | SELLER CONTACT | A group of business terms providing contact information about the Seller. |
| R57 |
|
BT-41 | +++ | 0..1 | Seller contact point | A contact point for a legal entity or person. | Such as person name, contact identification, department or office identification. | R57 | Text |
BT-42 | +++ | 0..1 | Seller contact telephone number | A phone number for the contact point. |
| R57 | Text |
BT-43 | +++ | 0..1 | Seller contact email address | An e-mail address for the contact point. |
| R57 | Text |
BG-7 | + | 1..1 | BUYER | A group of business terms providing information about the Buyer. |
| R57 |
|
BT-44 | ++ | 1..1 | Buyer name | The full name of the Buyer. |
| R57 | Text |
BT-45 | ++ | 0..1 | Buyer trading name | A name by which the Buyer is known, other than Buyer name (also known as Business name). | This may be used if different from the Buyer name. | R57 | Text |
BT-46 | ++ | 0..1 | Buyer identifier | An identifier of the Buyer. | If no scheme is specified, it should be known by Buyer and Seller, e.g. a previously exchanged Seller assigned identifier of the Buyer. | R57 | Identifier |
|
| 0..1 | Scheme identifier | The identification scheme identifier of the Buyer identifier. | If used, the identification scheme shall be chosen from the entries of the list published by the ISO/IEC 6523 maintenance agency. |
|
|
BT-47 | ++ | 0..1 | Buyer legal registration identifier | An identifier issued by an official registrar that identifies the Buyer as a legal entity or person. | If no identification scheme is specified, it should be known by Buyer and Seller, e.g. the identifier that is exclusively used in the applicable legal environment. | R47, R52, R57 | Identifier |
|
| 0..1 | Scheme identifier | The identification scheme identifier of the Buyer legal registration identifier. | If used, the identification scheme shall be chosen from the entries of the list published by the ISO/IEC 6523 maintenance agency. |
|
|
BT-48 | ++ | 0..1 | Buyer VAT identifier | The Buyer's VAT identifier (also known as Buyer VAT identification number). | VAT number prefixed by a country code based on EN ISO 3166‑1 "Codes for the representation of names of countries and their subdivisions" | R45, R52, R57 | Identifier |
BT-49 | ++ | 0..1 | Buyer electronic address | Identifies the Buyer's electronic address to which the invoice is delivered. |
| R13, R57 | Identifier |
|
| 1..1 | Scheme identifier | The identification scheme identifier of the Buyer electronic address. | The scheme identifier shall be chosen from [ANNOTATION: BY 'fred' ON '2020-10-30T11:02:00'f NOTE: '#24']the EAS (Electronic Address Scheme) lista list to be maintained by the Connecting Europe Facility. |
|
|
BG-8 | ++ | 1..1 | BUYER POSTAL ADDRESS | A group of business terms providing information about the postal address for the Buyer. | Sufficient components of the address are to be filled to comply with legal requirements. | R53 |
|
BT-50 | +++ | 0..1 | Buyer address line 1 | The main address line in an address. | Usually the street name and number or post office box. | R53 | Text |
BT-51 | +++ | 0..1 | Buyer address line 2 | An additional address line in an address that can be used to give further details supplementing the main line. |
| R53 | Text |
BT-163 | +++ | 0..1 | Buyer address line 3 | An additional address line in an address that can be used to give further details supplementing the main line. |
| R53 | Text |
BT-52 | +++ | 0..1 | Buyer city | The common name of the city, town or village, where the Buyer's address is located. |
| R53 | Text |
BT-53 | +++ | 0..1 | Buyer post code | The identifier for an addressable group of properties according to the relevant postal service. | Such as a ZIP code or a post code. | R53 | Text |
BT-54 | +++ | 0..1 | Buyer country subdivision | The subdivision of a country. | Such as a region, a county, a state, a province, etc. | R53 | Text |
BT-55 | +++ | 1..1 | Buyer country code | A code that identifies the country. | The lists of valid countries are registered with the EN ISO 3166‑1 Maintenance agency, “Codes for the representation of names of countries and their subdivisions”. | R53 | Code |
BG-9 | ++ | 0..1 | BUYER CONTACT | A group of business terms providing contact information relevant for the Buyer. | Contact details can be given by the Buyer at the time of the ordering or as master data exchanged prior to ordering. Contact details should not be used for the purpose of routing the received Invoice internally by the recipient; the Buyer reference identifier should be used for this purpose. | R57 |
|
BT-56 | +++ | 0..1 | Buyer contact point | A contact point for a legal entity or person. | Such as person name, contact identification, department or office identification. | R57 | Text |
BT-57 | +++ | 0..1 | Buyer contact telephone number | A phone number for the contact point. |
| R57 | Text |
BT-58 | +++ | 0..1 | Buyer contact email address | An e-mail address for the contact point. |
| R57 | Text |
BG-10 | + | 0..1 | PAYEE | A group of business terms providing information about the Payee, i.e. the role that receives the payment. | The role of Payee may be fulfilled by another party than the Seller, e.g. a factoring service. | R1, R57 |
|
BT-59 | ++ | 1..1 | Payee name | The name of the Payee. | Shall be used when the Payee is different from the Seller. The Payee name may however be the same as the Seller name. | R1, R57 | Text |
BT-60 | ++ | 0..1 | Payee identifier | An identifier for the Payee. | If no scheme is specified, it should be known by Buyer and Seller, e.g. a previously exchanged Buyer or Seller assigned identifier. | R1, R57 | Identifier |
|
| 0..1 | Scheme identifier | The identification scheme identifier of the Payee identifier. | If used, the identification scheme shall be chosen from the entries of the list published by the ISO/IEC 6523 maintenance agency. |
|
|
BT-61 | ++ | 0..1 | Payee legal registration identifier | An identifier issued by an official registrar that identifies the Payee as a legal entity or person. | If no scheme is specified, it should be known by Buyer and Seller, e.g. the identifier that is exclusively used in the applicable legal environment. | R1 | Identifier |
|
| 0..1 | Scheme identifier | The identification scheme identifier of the Payee legal registration identifier. | If used, the identification scheme shall be chosen from the entries of the list published by the ISO/IEC 6523 maintenance agency. |
|
|
BG-11 | + | 0..1 | SELLER TAX REPRESENTATIVE PARTY | A group of business terms providing information about the Seller's tax representative. |
| R57 |
|
BT-62 | ++ | 1..1 | Seller tax representative name | The full name of the Seller's tax representative party. |
| R57 | Text |
BT-63 | ++ | 1..1 | Seller tax representative VAT identifier | The VAT identifier of the Seller's tax representative party. | VAT number prefixed by a country code based on EN ISO 3166‑1 "Codes for the representation of names of countries and their subdivisions". | R52 | Identifier |
BG-12 | ++ | 1..1 | SELLER TAX REPRESENTATIVE POSTAL ADDRESS | A group of business terms providing information about the postal address for the tax representative party. | The Seller tax representative name/postal address shall be provided in the invoice, if the Seller has a tax representative who is liable to pay the VAT due. Sufficient components of the address are to be filled to comply with legal requirements. | R53 |
|
BT-64 | +++ | 0..1 | Tax representative address line 1 | The main address line in an address. | Usually the street name and number or the post office box. | R53 | Text |
BT-65 | +++ | 0..1 | Tax representative address line 2 | An additional address line in an address that can be used to give further details supplementing the main line. |
| R53 | Text |
BT-164 | +++ | 0..1 | Tax representative address line 3 | An additional address line in an address that can be used to give further details supplementing the main line. |
| R53 | Text |
BT-66 | +++ | 0..1 | Tax representative city | The common name of the city, town or village, where the tax representative address is located. |
| R53 | Text |
BT-67 | +++ | 0..1 | Tax representative post code | The identifier for an addressable group of properties according to the relevant postal service. | Such as a ZIP code or a post code. | R53 | Text |
BT-68 | +++ | 0..1 | Tax representative country subdivision | The subdivision of a country. | Such as a region, a county, a state, a province, etc. | R53 | Text |
BT-69 | +++ | 1..1 | Tax representative country code | A code that identifies the country. | Country where VAT is liable. The lists of valid countries are registered with the EN ISO 3166‑1 Maintenance agency, “Codes for the representation of names of countries and their subdivisions”. | R53 | Code |
BG-13 | + | 0..1 [ANNOTATION: BY 'Fred van Blommestein' ON '2020-11-09T18:19:00'FvB NOTE: '#49']n | DELIVERY INFORMATION | A group of business terms providing information about where and when the goods and services invoiced are delivered. |
| R31, R32, R57 |
|
BT-70 | ++ | 0..1 | Deliver to party name | The name of the party to which the goods and services are delivered. | Shall be used if the Deliver to party is different from the Buyer. | R57 | Text |
BT-71 | ++ | 0..1 | Deliver to location identifier | An identifier for the location at which the goods and services are delivered. | If no scheme is specified, it should be known by Buyer and Seller, e.g. a previously exchanged Buyer or Seller assigned identifier. | R32 | Identifier |
|
| 0..1 | Scheme identifier | The identification scheme identifier of the Deliver to location identifier. | If used, the identification scheme shall be chosen from the entries of the list published by the ISO/IEC 6523 maintenance agency. |
|
|
BT-72 | ++ | 0..1 | Actual delivery date | the date on which the supply of goods or services was made or completed. |
| R31 | Date |
BG-14 | ++ | 0..1 | INVOICING PERIOD | A group of business terms providing information on the invoice period. | Used to indicate when the period covered by the invoice starts and when it ends. Also called delivery period. | R34 |
|
BT-73 | +++ | 0..1 | Invoicing period start date | The date when the Invoice period starts. | The initial date of delivery of goods or services. | R34 | Date |
BT-74 | +++ | 0..1 | Invoicing period end date | The date when the Invoice period ends. | The date on which the delivery of goods or services was completed. | R34 | Date |
BG-15 | ++ | n0..1 [ANNOTATION: BY 'Fred van Blommestein' ON '2020-11-09T18:19:00'FvB NOTE: '#49']1 | DELIVER TO ADDRESS | A group of business terms providing information about the address to which goods and services invoiced were or are delivered. | In the case of pick-up, the deliver to address is the pick-up address. Sufficient components of the address are to be filled to comply with legal requirements. | R32 |
|
BT-75 | +++ | 0..1 | Deliver to address line 1 | The main address line in an address. | Usually the street name and number. | R32 | Text |
BT-76 | +++ | 0..1 | Deliver to address line 2 | An additional address line in an address that can be used to give further details supplementing the main line. |
| R32 | Text |
BT-165 | +++ | 0..1 | Deliver to address line 3 | An additional address line in an address that can be used to give further details supplementing the main line. |
| R32 | Text |
BT-77 | +++ | 0..1 | Deliver to city | The common name of the city, town or village, where the deliver to address is located. |
| R32 | Text |
BT-78 | +++ | 0..1 | Deliver to post code | The identifier for an addressable group of properties according to the relevant postal service. | Such as a ZIP code or a post code. | R32 | Text |
BT-79 | +++ | 0..1 | Deliver to country subdivision | The subdivision of a country. | Such as a region, a county, a state, a province, etc. | R32 | Text |
BT-80 | +++ | 1..1 | Deliver to country code | A code that identifies the country. | The lists of valid countries are registered with the EN ISO 3166‑1 Maintenance agency, “Codes for the representation of names of countries and their subdivisions”. | R32 | Code |
BG-16 | + | 0..1 [ANNOTATION: BY 'Fred van Blommestein' ON '2020-11-09T17:44:00'FvB NOTE: '#45']n | PAYMENT INSTRUCTIONS | A group of business terms providing information about the payment. |
| R58 |
|
[ANNOTATION: BY 'Fred van Blommestein' ON '2020-11-09T17:45:00'FvB NOTE: '#45']BT-XXX166 | ++ | 0..1 | Amount to be paid | The amount to be paid according this payment instruction | In case of a split payment. May be the amount to be withheld. |
| Amount |
BT-81 | ++ | 1..1 | Payment means type code | The means, expressed as code, for how a payment is expected to be or has been settled. | Entries from the UNTDID 4461 code list [6] shall be used. Distinction should be made between SEPA and non-SEPA payments, and between credit payments, direct debits, card payments and other instruments. | R58 | Code |
BT-82 | ++ | 0..1 | Payment means text | The means, expressed as text, for how a payment is expected to be or has been settled. | Such as cash, credit transfer, direct debit, credit card, etc. | R58 | Text |
BT-83 | ++ | 0..1 | Remittance information | A textual value used to establish a link between the payment and the Invoice, issued by the Seller. | Used for creditor's critical reconciliation information. This information element helps the Seller to assign an incoming payment to the relevant payment process. When specifying the textual value, which is commonly the invoice number of the invoice being paid, but may be another seller reference, the buyer should indicate this reference in his payment order when executing the payment. In a payment transaction this reference is transferred back to the Seller as Remittance Information. | R56, R62 | Text |
|
|
|
|
| In order to allow for automatic processing of cross-border SEPA payments, only Latin characters should be used in this field, with a maximum of 140 characters. Reference section 1.4 of the SEPA credit transfer and SEPA direct debit scheme implementation guides [13] and [14] for details of the allowed characters. Other rules may apply for SEPA payments within national borders. |
|
|
If remittance information is structured according to the ISO 11649:2009 standard [16] for Structured RF Creditor Reference, it shall be mapped to the Structured Remittance Information Creditor Reference field in SEPA payments messages. If remittance information is structured according to the EACT standard for automated reconciliation [17], it shall be mapped to the Unstructured Remittance Information field in SEPA payments messages.” | |||||||
If remittance information is to be mapped to the End To End Identification field or to the Structured Remittance Information Creditor Reference field in SEPA payments messages, then in addition to the Latin character set restriction, the content shall not start or end with a '/' and the content shall not contain '//'s. See reference [15]. | |||||||
BG-17 | ++ | 0..n [ANNOTATION: BY 'Fred van Blommestein' ON '2020-11-09T17:47:00'FvB NOTE: '#45']1 | CREDIT TRANSFER | A group of business terms to specify credit transfer payments. |
| R58 |
|
BT-84 | +++ | 1..1 | Payment account identifier | A unique identifier of the financial payment account, at a payment service provider, to which payment should be made. | Such as IBAN (in case of a SEPA payment) or a national account number. | R61, R65 | Identifier |
BT-85 | +++ | 0..1 | Payment account name | The name of the payment account, at a payment service provider, to which payment should be made. |
| R61, R65 | Text |
BT-86 | +++ | 0..1 | Payment service provider identifier | An identifier for the payment service provider where a payment account is located. | Such as a BIC or a national clearing code where required. No identification scheme to be used. | R61, R65 | Identifier |
BG-18 | ++ | 0..1 | PAYMENT CARD INFORMATION | A group of business terms providing information about card used for payment contemporaneous with invoice issuance. | Only used if the Buyer had opted to pay by using a payment card such as a credit or debit card. | R64 |
|
BT-87 | +++ | 1..1 | Payment card primary account number | The Primary Account Number (PAN) of the card used for payment. | In accordance with card payments security standards an invoice should never include a full card primary account number. At the moment PCI Security Standards Council has defined that the first 6 digits and last 4 digits are the maximum number of digits to be shown. | R64 | Text |
BT-88 | +++ | 0..1 | Payment card holder name | The name of the payment card holder. |
| R64 | Text |
BG-19 | ++ | 0..1 | DIRECT DEBIT | A group of business terms to specify a direct debit. | This group may be used to give prior notice in the invoice that payment will be made through a SEPA or other direct debit initiated by the Seller, in accordance with the rules of the SEPA or other direct debit scheme. | R69 |
|
BT-89 | +++ | 0..1 | Mandate reference identifier | Unique identifier assigned by the Payee for referencing the direct debit mandate. | Used in order to pre-notify the Buyer of a SEPA direct debit. | R69 | Identifier |
BT-90 | +++ | 0..1 | Bank assigned creditor identifier | Unique banking reference identifier of the Payee or Seller assigned by the Payee or Seller bank. | Used in order to pre-notify the Buyer of a SEPA direct debit. | R69 | Identifier |
BT-91 | +++ | 0..1 | Debited account identifier | The account to be debited by the direct debit. |
| R69 | Identifier |
BG-20 | + | 0..n | DOCUMENT LEVEL ALLOWANCES | A group of business terms providing information about allowances applicable to the Invoice as a whole. | Deductions, such as withheld tax may also be specified in this group. | R15 |
|
BT-92 | ++ | 1..1 | Document level allowance amount | The amount of an allowance, without VAT. |
| R15, R19 | Amount2 |
BT-93 | ++ | 0..1 | Document level allowance base amount | The base amount that may be used, in conjunction with the document level allowance percentage, to calculate the document level allowance amount. |
| R15, R42 | Amount2 |
BT-94 | ++ | 0..1 | Document level allowance percentage | The percentage that may be used, in conjunction with the document level allowance base amount, to calculate the document level allowance amount. |
| R15, R42 | Percentage |
BT-95 | ++ | 1..1 | Document level allowance VAT category code | A coded identification of what VAT category applies to the document level allowance. | The following entries of UNTDID 5305 [6] are used (further clarification between brackets): - Standard rate (Liable for VAT in a standard way) - Zero rated goods (Liable for VAT with a percentage rate of zero) - Exempt from tax (VAT/IGIC/IPSI) - VAT Reverse Charge (Reverse charge VAT/IGIC/IPSI rules apply) - VAT exempt for intra community supply of goods (VAT/IGIC/IPSI not levied due to Intra-community supply rules) - Free export item, tax not charged (VAT/IGIC/IPSI not levied due to export outside of the EU) - Services outside scope of tax (Sale is not subject to VAT/IGIC/IPSI) - Canary Islands General Indirect Tax (Liable for IGIC tax) - Liable for IPSI (Ceuta/Melilla tax) [ANNOTATION: BY 'Sara Facchinetti' ON '2020-11-10T12:52:00'SF NOTE: '#39']- Transferred (VAT) for Italian split payment [ANNOTATION: BY 'Fred van Blommestein' ON '2020-11-09T17:23:00'FvB NOTE: '#20']- Specific national regulation (to be detailed in the Exemption reason) | R15, R16, R45, R48 | Code |
BT-96 | ++ | 0..1 | Document level allowance VAT rate | The VAT rate, represented as percentage that applies to the document level allowance. |
| R15, R16, R45, R48 | Percentage |
[ANNOTATION: BY 'Fred van Blommestein' ON '2020-11-03T14:06:00'FvB NOTE: '#26, #43']BT-XXX167 | +++ | 0..1 | Document Level Allowance VAT exemption reason text | A textual statement of the reason why the amount is exempted from VAT or why no VAT is being charged | Articles 226 items 11 to 15 Directive 2006/112/EC [2]. | R48, R49, R51 | Text |
[ANNOTATION: BY 'Fred van Blommestein' ON '2020-11-03T14:06:00'FvB NOTE: '#26']BT-XXX168 | +++ | 0..1 | Document Level Allowance VAT exemption reason code | A coded statement of the reason for why the amount is exempted from VAT. | VATEX (VAT Exemption Reasons) code list. | R48, R49, R51 R55 | Code |
BT-97 | ++ | 0..1 | Document level allowance reason | The reason for the document level allowance, expressed as text. |
| R15 | Text |
BT-98 | ++ | 0..1 | Document level allowance reason code | The reason for the document level allowance, expressed as a code. | Use entries of the UNTDID 5189 code list [6]. The Document level allowance reason code and the Document level allowance reason shall indicate the same allowance reason. | R15 | Code |
[ANNOTATION: BY 'Sara Facchinetti' ON '2020-11-10T12:02:00'SF NOTE: '#29 ']BT-169 | ++ | 0..1 | Document level allowance tax withheld indicator | Indicator that shows that the allowance amount is subject to tax withholding process | Yes or no |
| |
BG-21 | + | 0..n | DOCUMENT LEVEL CHARGES | A group of business terms providing information about charges and taxes other than VAT, applicable to the Invoice as a whole. |
| R15 |
|
BT-99 | ++ | 1..1 | Document level charge amount | The amount of a charge, without VAT. |
| R15, R16, R19 | Amount2 |
BT-100 | ++ | 0..1 | Document level charge base amount | The base amount that may be used, in conjunction with the document level charge percentage, to calculate the document level charge amount. |
| R15, R16, R19 | Amount2 |
BT-101 | ++ | 0..1 | Document level charge percentage | The percentage that may be used, in conjunction with the document level charge base amount, to calculate the document level charge amount. |
| R15, R16, R19 | Percentage |
BT-102 | ++ | 1..1 | Document level charge VAT category code | A coded identification of what VAT category applies to the document level charge. | The following entries of UNTDID 5305 [6] are used (further clarification between brackets): - Standard rate (Liable for VAT in a standard way) - Zero rated goods (Liable for VAT with a percentage rate of zero) - Exempt from tax (VAT/IGIC/IPSI) - VAT Reverse Charge (Reverse charge VAT/IGIC/IPSI rules apply) - VAT exempt for intra community supply of goods (VAT/IGIC/IPSI not levied due to Intra-community supply rules) - Free export item, tax not charged (VAT/IGIC/IPSI not levied due to export outside of the EU) - Services outside scope of tax (Sale is not subject to VAT/IGIC/IPSI) - Canary Islands General Indirect Tax (Liable for IGIC tax) - Liable for IPSI (Ceuta/Melilla tax) [ANNOTATION: BY 'Sara Facchinetti' ON '2020-11-10T12:52:00'SF NOTE: '#39']- Transferred (VAT) for Italian split payment [ANNOTATION: BY 'Fred van Blommestein' ON '2020-11-09T17:23:00'FvB NOTE: '#20']- Specific national regulation (to be detailed in the Exemption reason) | R15, R45, R48 | Code |
BT-103 | ++ | 0..1 | Document level charge VAT rate | The VAT rate, represented as percentage that applies to the document level charge. |
| R15, R45, R48 | Percentage |
[ANNOTATION: BY 'Fred van Blommestein' ON '2020-11-03T14:06:00'FvB NOTE: '#26, #43']BT-XXX170 | +++ | 0..1 | Document Level Charge VAT exemption reason text | A textual statement of the reason why the amount is exempted from VAT or why no VAT is being charged | Articles 226 items 11 to 15 Directive 2006/112/EC [2]. | R48, R49, R51 | Text |
[ANNOTATION: BY 'Fred van Blommestein' ON '2020-11-03T14:06:00'FvB NOTE: '#26']BT-XXX171 | +++ | 0..1 | Document Level Charge VAT exemption reason code | A coded statement of the reason for why the amount is exempted from VAT. | VATEX (VAT Exemption Reasons) code list. | R48, R49, R51 R55 | Code |
BT-104 | ++ | 0..1 | Document level charge reason | The reason for the document level charge, expressed as text. |
| R15, R16 | Text |
BT-105 | ++ | 0..1 | Document level charge reason code | The reason for the document level charge, expressed as a code. | Use entries of the UNTDID 7161 code list [6]. The Document level charge reason code and the Document level charge reason shall indicate the same charge reason. | R15, R16 | Code |
[ANNOTATION: BY 'Sara Facchinetti' ON '2020-11-10T12:02:00'SF NOTE: '#29 ']BT-172 | ++ | 0..1 | Document level charge tax withheld indicator | Indicator that shows that the charge amount is subject to tax withholding process | Yes or no |
| Text |
BG-22 | + | 1..1 | DOCUMENT TOTALS | A group of business terms providing the monetary totals for the Invoice. |
| R40 |
|
BT-106 | ++ | 1..1 | Sum of Invoice line net amount | Sum of all Invoice line net amounts in the Invoice. |
| R40 | Amount |
BT-107 | ++ | 0..1 | Sum of allowances on document level | Sum of all allowances on document level in the Invoice. | Allowances on line level are included in the Invoice line net amount which is summed up into the Sum of Invoice line net amount. | R19, R40 | Amount |
BT-108 | ++ | 0..1 | Sum of charges on document level | Sum of all charges on document level in the Invoice. | Charges on line level are included in the Invoice line net amount which is summed up into the Sum of Invoice line net amount. | R19, R40 | Amount |
BT-109 | ++ | 1..1 | Invoice total amount without VAT | The total amount of the Invoice without VAT. | The Invoice total amount without VAT is the Sum of VAT category tax amounts” Invoice line net amount minus Sum of allowances on document level plus Sum of charges on document level. | R40 | Amount |
BT-110 | ++ | 0..1 | Invoice total VAT amount | The total VAT amount for the Invoice. | The Invoice total VAT amount is the sum of all VAT category tax amounts. | R40, R49 | Amount |
BT-111 | ++ | 0..1 | Invoice total VAT amount in accounting currency | The VAT total amount expressed in the accounting currency accepted or required in the country of the Seller. | To be used when the VAT accounting currency (BT-6) differs from the Invoice currency code (BT-5) in accordance with article 230 of Directive 2006/112 / EC on VAT. The VAT amount in accounting currency is not used in the calculation of the Invoice totals. | R54 | Amount |
BT-112 | ++ | 1..1 | Invoice total amount with VAT | The total amount of the Invoice with VAT. | The Invoice total amount with VAT is the Invoice total amount without VAT plus the Invoice total VAT amount. | R40, R67 | Amount |
BT-113 | +++ | 0..1 | Paid amount | The sum of amounts which have been paid in advance [ANNOTATION: BY 'Fred van Blommestein' ON '2020-11-03T14:14:00'FvB NOTE: '#28']or shall not be calculated into the amount due for payment [ANNOTATION: BY 'Sara Facchinetti' ON '2020-11-10T12:50:00'SF NOTE: '#39'](e.g. split payment amount). | This amount is subtracted from the invoice total amount with VAT to calculate the amount due for payment. | R40, R66 | Amount |
BT-114 | ++ | 0..1 | Rounding amount | The amount to be added to the invoice total to round the amount to be paid. |
| R40 | Amount |
BT-115 | ++ | 1..1 | Amount due for payment | The outstanding amount that is requested to be paid. | This amount is the Invoice total amount with VAT minus the paid amount that has been paid in advance. The amount is zero in case of a fully paid Invoice. The amount may be negative; in that case the Seller owes the amount to the Buyer. | R40, R59, R68 | Amount |
[ANNOTATION: BY 'Fred van Blommestein' ON '2020-11-03T14:32:00'FvB NOTE: '#29']BG-XX33 | + | 0..1n | Tax withheld. | Part of the tax or social securities amount that is not to be paid to the Seller. |
|
| |
[ANNOTATION: BY 'Fred van Blommestein' ON '2020-11-03T14:33:00'FvB NOTE: '#29']BT-XXX172 | ++ | 1..1 | Amount withheld. | Amount that is not to be paid to the Seller. |
|
| Amount |
[ANNOTATION: BY 'Fred van Blommestein' ON '2020-11-03T14:33:00'FvB NOTE: '#29']BT-XXX173 | ++ | 0..1 | Withheld base amount. | Base of the amount that is not to be paid to the Seller. |
|
| Amount |
[ANNOTATION: BY 'Fred van Blommestein' ON '2020-11-03T14:33:00'FvB NOTE: '#29']BT-XXX174 | ++ | 0..1 | Withheld percentage. | Percentage of the base amount that is not to be paid to the Seller. |
|
| Percentage |
BT-175 | ++ | 0..1 | Tax withheld reason text | Description/Reason of tax withholding process |
|
| Text |
BG-23 | + | 1..n | VAT BREAKDOWN | A group of business terms providing information about VAT breakdown by different categories, rates and exemption reasons |
| R38, R45, R47, R48, R49 |
|
BT-116 | ++ | 1..1 | VAT category taxable amount | Sum of all taxable amounts subject to a specific VAT category code and VAT category rate (if the VAT category rate is applicable). | The sum of Invoice line net amount minus allowances plus charges on document level which are subject to a specific VAT category code and VAT category rate (if the VAT category rate is applicable). | R50 | Amount |
BT-117 | ++ | 1..1 | VAT category tax amount | The total VAT amount for a given VAT category. | Calculated by multiplying the VAT category taxable amount with the VAT category rate for the relevant VAT category. | R49 | Amount |
BT-118 | ++ | 1..1 | VAT category code | Coded identification of a VAT category. | The following entries of UNTDID 5305 [6] are used (further clarification between brackets): - Standard rate (Liable for VAT in a standard way) - Zero rated goods (Liable for VAT with a percentage rate of zero) - Exempt from tax (VAT/IGIC/IPSI) - VAT Reverse Charge (Reverse charge VAT/IGIC/IPSI rules apply) - VAT exempt for intra community supply of goods (VAT/IGIC/IPSI not levied due to Intra-community supply rules) - Free export item, tax not charged (VAT/IGIC/IPSI not levied due to export outside of the EU) - Services outside scope of tax (Sale is not subject to VAT/IGIC/IPSI) - Canary Islands General Indirect Tax (Liable for IGIC tax) - Liable for IPSI (Ceuta/Melilla tax) [ANNOTATION: BY 'Sara Facchinetti' ON '2020-11-10T12:52:00'SF NOTE: '#39']- Transferred (VAT) for Italian split payment [ANNOTATION: BY 'Fred van Blommestein' ON '2020-11-09T17:23:00'FvB NOTE: '#20']- Specific national regulation (to be detailed in the Exemption reason) | R38, R45, R49 | Code |
BT-119 | ++ | 0..1 | VAT category rate | The VAT rate, represented as percentage that applies for the relevant VAT category. | The VAT category code and the VAT category rate shall be consistent. | R38, R49 | Percentage |
BT-120 | ++ | 0..1 | VAT exemption reason text | A textual statement of the reason why the amount is exempted from VAT or why no VAT is being charged | Articles 226 items 11 to 15 Directive 2006/112/EC [2]. | R48, R49, R51 | Text |
BT-121 | ++ | 0..1 | VAT exemption reason code | A coded statement of the reason for why the amount is exempted from VAT. | [ANNOTATION: BY 'fred' ON '2020-10-30T11:02:00'f NOTE: '#25']VATEX (VAT Exemption Reasons) code listCode list issued and maintained by the Connecting Europe Facility. | R48, R49, R51 R55 | |
BG-24 | + | 0..n | ADDITIONAL SUPPORTING DOCUMENTS | A group of business terms providing information about additional supporting documents substantiating the claims made in the Invoice. | The additional supporting documents can be used for both referencing a document number which is expected to be known by the receiver, an external document (referenced by a URL) or as an embedded document (such as a time report in pdf). The option to link to an external document will be needed, for example in the case of large attachments and/or when sensitive information, e.g. person-related services, has to be separated from the Invoice itself. | R36 |
|
BT-122 | ++ | 1..1 | Supporting document reference | An identifier of the supporting document. |
| R36 | Document reference |
BT-123 | ++ | 0..1 | Supporting document description | A description of the supporting document. | Such as: timesheet, usage report etc. | R36 | Text |
BT-124 | ++ | 0..1 | External document location | The URL (Uniform Resource Locator) that identifies where the external document is located. | A means of locating the resource including its primary access mechanism, e.g. http:// or ftp://. External document location shall be used if the Buyer requires additional information to support the Invoice. External documents do not form part of the invoice. Risks can be involved when accessing external documents. | R36 | Text |
BT-125 | ++ | 0..1 | Attached document | An attached document embedded as binary object or sent together with the invoice. | Attached document is used when documentation shall be stored with the Invoice for future reference or audit purposes. [ANNOTATION: BY 'Fred van Blommestein' ON '2020-10-30T11:02:00'FvB NOTE: '#14']A Receiver of an Invoice, compliant to the core invoice model may accept and process the following types of attachments with a warning. A warning is given because the processing of a structured attachment requires the knowledge of its semantics, which have to be given via a bilateral agreement,931.
| R35 | Binary object
|
|
| 1..1 | Attached document Mime code | The mime code of the attached document. | Allowed mime codes: - application/pdf - image/png - image/jpeg - text/csv - application/vnd.openxmlformats-officedocument.spreadsheetml.sheet - application/vnd.oasis.opendocument. spreadsheet [ANNOTATION: BY 'Fred van Blommestein' ON '2020-10-30T11:02:00'FvB NOTE: '#14']— application/xml (.xml). |
|
|
|
| 1..1 | Attached document Filename | The file name of the attached document |
|
|
|
BG-25 | + | 1..n | INVOICE LINE | A group of business terms providing information on individual Invoice lines. |
| R17 R23 R27 |
|
BT-126 | ++ | 1..1 | Invoice line identifier | A unique identifier for the individual line within the Invoice. |
| R44 | Identifier |
BT-127 | ++ | 0..1 | Invoice line note | A textual note that gives unstructured information that is relevant to the Invoice line. |
| R28 | Text |
BT-128 | ++ | [ANNOTATION: BY 'Fred van Blommestein' ON '2021-02-04T14:18:00'FvB NOTE: '#91']0..1n | Invoice line object identifier | An identifier for an object on which the invoice line is based, given by the Seller. | It may be a subscription number, telephone number, meter point etc., as applicable. It is possible to reference multiple types of reference (not multiple references of the same type). | R33 | Identifier |
|
| 0..1 | Scheme identifier | The identification scheme identifier of the Invoice line object identifier. | If it may be not clear for the receiver what scheme is used for the identifier, a conditional scheme identifier should be used that shall be chosen from the UNTDID 1153 code list [6] entries. |
|
|
BT-129 | ++ | 1..1 | Invoiced quantity | The quantity of items (goods or services) that is charged in the Invoice line. |
| R39, R56 | Quantity |
BT-130 | ++ | 1..1 | Invoiced quantity unit of measure code | The unit of measure that applies to the invoiced quantity. | The unit of measure shall be chosen from the lists in UN/ECE Recommendation N°. 20 “Codes for Units of Measure Used in International Trade” [7] and UN/ECE Recommendation N° 21 “Codes for Passengers, Types of Cargo, Packages and Packaging Materials (with Complementary Codes for Package Names)” [19] applying the method described in UN/ECE Rec N° 20 Intro 2.a). Note that in most cases it is not needed for Buyers and Sellers to implement these lists fully in their software. Sellers need only to support the units needed for their goods and services; Buyers only need to verify that the units used in the Invoice are equal to the units used in other documents (such as Contract, Catalogue, Order and Despatch advice). | R14, R39 | Code |
BT-131 | ++ | 1..1 | Invoice line net amount | The total amount of the Invoice line. | The amount is “net” without VAT, i.e. inclusive of line level allowances and charges as well as other relevant taxes. | R39, R40, R56 | Amount2 |
[ANNOTATION: BY 'Sara Facchinetti' ON '2020-11-10T12:02:00'SF NOTE: '#29 ']BT-176 | ++ | 0..1 | Invoice line tax withheld indicator | Indicator that shows that the Invoice line amount is subject to tax withholding process | Yes or no |
| Text |
[ANNOTATION: BY 'Fred van Blommestein' ON '2020-11-09T18:22:00'FvB NOTE: '#50, #49']BT-XXX177 | ++ | 0..1 | Referenced purchase order reference | An identifier for a referenced purchase order, issued by the Buyer. |
|
| |
[ANNOTATION: BY 'Fred van Blommestein' ON '2020-11-09T18:22:00'FvB NOTE: '#50, #49']BT-XXX178 | ++ | 0..1 | Referenced sales order reference | An identifier for a referenced sales order, issued by the Seller. |
|
| Text |
[ANNOTATION: BY 'Fred van Blommestein' ON '2020-11-09T18:22:00'FvB NOTE: '#49']BT-XXX179 | ++ | 0..1 | Referenced despatch advice reference | An identifier for a referenced despatch advice, issued by the Seller. |
|
| Text |
[ANNOTATION: BY 'Fred van Blommestein' ON '2020-11-09T18:22:00'FvB NOTE: '#49']BT-XXX180 | ++ | 0..1 | Referenced receiving advice reference | An identifier for a referenced receiving advice, issued by the Buyer. |
|
| Text |
BT-132 | ++ | 0..1 | Referenced purchase order line reference | An identifier for a referenced line within a purchase order, issued by the Buyer. | The purchase order identifier is [ANNOTATION: BY 'Fred van Blommestein' ON '2020-11-09T18:23:00'FvB NOTE: '#50']may be referenced on document level. | R6 | Document reference |
BT-133 | ++ | 0..1 | Invoice line Buyer accounting reference | A textual value that specifies where to book the relevant data into the Buyer's financial accounts. | If required, this reference shall be provided by the Buyer to the Seller prior to the issuing of the Invoice. | R3 | Text |
BG-26 | ++ | 0..1 | INVOICE LINE PERIOD | A group of business terms providing information about the period relevant for the Invoice line. | Is also called Invoice line delivery period. | R30 |
|
BT-134 | +++ | 0..1 | Invoice line period start date | The date when the Invoice period for this Invoice line starts. | The date is the first day of the period. | R30 | Date |
BT-135 | +++ | 0..1 | Invoice line period end date | The date when the Invoice period for this Invoice line ends. | The date is the last day of the period. | R30 | Date |
BG-27 | ++ | 0..n | INVOICE LINE ALLOWANCES | A group of business terms providing information about allowances applicable to the individual Invoice line. |
| R15 |
|
BT-136 | +++ | 1..1 | Invoice line allowance amount | The amount of an allowance, without VAT. |
| R15, R19 | Amount2 |
BT-137 | +++ | 0..1 | Invoice line allowance base amount | The base amount that may be used, in conjunction with the Invoice line allowance percentage, to calculate the Invoice line allowance amount. |
| R15, R42 | Amount2 |
BT-138 | +++ | 0..1 | Invoice line allowance percentage | The percentage that may be used, in conjunction with the Invoice line allowance base amount, to calculate the Invoice line allowance amount. |
| R15, R42 | Percentage |
BT-139 | +++ | 0..1 | Invoice line allowance reason | The reason for the Invoice line allowance, expressed as text. |
| R15 | Text |
BT-140 | +++ | 0..1 | Invoice line allowance reason code | The reason for the Invoice line allowance, expressed as a code. | Use entries of the UNTDID 5189 code list [6]. The Invoice line level allowance reason code and the Invoice line level allowance reason shall indicate the same allowance reason. | R15 | Code |
BG-28 | ++ | 0..n | INVOICE LINE CHARGES | A group of business terms providing information about charges and taxes other than VAT applicable to the individual Invoice line. | All charges and taxes are assumed to be liable to the same VAT rate as the Invoice line. | R18 |
|
BT-141 | +++ | 1..1 | Invoice line charge amount | The amount of a charge, without VAT. |
| R19 | Amount2 |
BT-142 | +++ | 0..1 | Invoice line charge base amount | The base amount that may be used, in conjunction with the Invoice line charge percentage, to calculate the Invoice line charge amount. |
| R42 | Amount2 |
BT-143 | +++ | 0..1 | Invoice line charge percentage | The percentage that may be used, in conjunction with the Invoice line charge base amount, to calculate the Invoice line charge amount. |
| R42 | Percentage |
BT-144 | +++ | 0..1 | Invoice line charge reason | The reason for the Invoice line charge, expressed as text. |
| R18 | Text |
BT-145 | +++ | 0..1 | Invoice line charge reason code | The reason for the Invoice line charge, expressed as a code. | Use entries of the UNTDID 7161 code list [6]. The Invoice line charge reason code and the Invoice line charge reason shall indicate the same charge reason. | R18 | Code |
BG-29 | ++ | 1..1 | PRICE DETAILS | A group of business terms providing information about the price applied for the goods and services invoiced on the Invoice line. |
| R14 |
|
BT-146 | +++ | 1..1 | Item net price | The price of an item, exclusive of VAT, after subtracting item price discount. | The Item net price has to be equal with the Item gross price less the Item price discount. | R14 | Unit price amount |
BT-147 | +++ | 0..1 | Item price discount | The total discount subtracted from the Item gross price to calculate the Item net price. | Only applies if the discount is provided per unit and if it is not included in the Item gross price. | R14 | Unit price amount |
BT-148 | +++ | 0..1 | Item gross price | The unit price, exclusive of VAT, before subtracting Item price discount. |
| R14 | Unit price amount |
[ANNOTATION: BY 'Fred van Blommestein' ON '2020-11-12T07:18:00'FvB NOTE: '#2']BT-XXX181 | +++ | 0..1 | Item VAT inclusive price | The price of an item per base quantity, inclusive of VAT. |
|
| Unit price amount |
BT-149 | +++ | 0..1 | Item price base quantity | The number of item units to which the price applies. | [ANNOTATION: BY 'Fred van Blommestein' ON '2020-11-06T14:08:00'FvB NOTE: '#42']The Item price base quantity shall not be negative. | R14 | Quantity |
BT-150 | +++ | 0..1 | Item price base quantity unit of measure code | The unit of measure that applies to the Item price base quantity. | The Item price base quantity unit of measure shall be the same as the Invoiced quantity unit of measure (BT-130). | R14 | Code |
BG-30 | ++ | 1..1 | LINE VAT INFORMATION | A group of business terms providing information about the VAT applicable for the goods and services invoiced on the Invoice line. |
| R45, R48 |
|
BT-151 | +++ | 1..1 | Invoiced item VAT category code | The VAT category code for the invoiced item. | The following entries of UNTDID 5305 [6] are used (further clarification between brackets): - Standard rate (Liable for VAT in a standard way) - Zero rated goods (Liable for VAT with a percentage rate of zero) - Exempt from tax (VAT/IGIC/IPSI) - VAT Reverse Charge (Reverse charge VAT/IGIC/IPSI rules apply) - VAT exempt for intra community supply of goods (VAT/IGIC/IPSI not levied due to Intra-community supply rules) - Free export item, tax not charged (VAT/IGIC/IPSI not levied due to export outside of the EU) - Services outside scope of tax (Sale is not subject to VAT/IGIC/IPSI) - Canary Islands General Indirect Tax (Liable for IGIC tax) - Liable for IPSI (Ceuta/Melilla tax) [ANNOTATION: BY 'Sara Facchinetti' ON '2020-11-10T12:52:00'SF NOTE: '#39']- Transferred (VAT) for Italian split payment [ANNOTATION: BY 'Fred van Blommestein' ON '2020-11-09T17:23:00'FvB NOTE: '#20']- Specific national regulation (to be detailed in the Exemption reason) | R37, R45, R48, R55 | Code |
BT-152 | +++ | 0..1 | Invoiced item VAT rate | The VAT rate, represented as percentage that applies to the invoiced item. |
| R37, R45, R48 | Percent |
[ANNOTATION: BY 'Fred van Blommestein' ON '2020-11-12T07:25:00'FvB NOTE: '#8']BT-XXX182 | +++ | 0..1 | Invoiced item VAT amount | The VAT amount that applies to the invoiced item |
|
| Amount |
[ANNOTATION: BY 'Fred van Blommestein' ON '2020-11-03T14:06:00'FvB NOTE: '#26']BT-XXX183 | +++ | 0..1 | Invoiced item VAT exemption / out of scope reason text | A textual statement of the reason why the amount is exempted from VAT or why no VAT is being charged | Articles 226 items 11 to 15 Directive 2006/112/EC [2]. | R48, R49, R51 | Text |
[ANNOTATION: BY 'Fred van Blommestein' ON '2020-11-03T14:06:00'FvB NOTE: '#26']BT-XXX184 | +++ | 0..1 | Invoiced item VAT exemption / out of scope reason code | A coded statement of the reason for why the amount is exempted from VAT or why no VAT is being charged. | VATEX (VAT Exemption Reasons) code list. | R48, R49, R51 R55 | Code |
BG-31 | ++ | 1..1 | ITEM INFORMATION | A group of business terms providing information about the goods and services invoiced. |
| R20, R56, R25, R26 |
|
BT-153 | +++ | 1..1 | Item name | A name for an item. |
| R20, R56 | Text |
BT-154 | +++ | 0..1 | Item description | A description for an item.
| The Item description allows for describing the item and its features in more detail than the Item name. | R20, R56 | Text |
BT-155 | +++ | 0..1 | Item Seller's identifier | An identifier, assigned by the Seller, for the item. |
| R21, R56 | Identifier |
BT-156 | +++ | 0..1 | Item Buyer's identifier | An identifier, assigned by the Buyer, for the item. |
| R21, R56, R22 | Identifier |
BT-157 | +++ | 0..1 | Item standard identifier | An item identifier based on a registered scheme. |
| R23, R56 | Identifier |
|
| 1..1 | Scheme identifier | The identification scheme identifier of the Item standard identifier | The identification scheme shall be identified from the entries of the list published by the ISO/IEC 6523 maintenance agency. |
|
|
BT-158 | +++ | 0..n | Item classification identifier | A code for classifying the item by its type or nature. | Classification codes are used to allow grouping of similar items for a various purposes e.g. public procurement (CPV), e-Commerce (UNSPSC) etc. | R24 | Identifier |
|
| 1..1 | Scheme identifier | The identification scheme identifier of the Item classification identifier | The identification scheme shall be chosen from the entries in UNTDID 7143 [6]. |
|
|
|
| 0..1 | Scheme version identifier | The version of the identification scheme. |
|
|
|
BT-159 | +++ | 0..1 | Item country of origin | The code identifying the country from which the item originates. | The lists of valid countries are registered with the EN ISO 3166‑1 Maintenance agency, “Codes for the representation of names of countries and their subdivisions”. | R29 | Code |
BG-32 | +++ | 0..n | ITEM ATTRIBUTES | A group of business terms providing information about properties of the goods and services invoiced. |
| R28 |
|
BT-160 | ++++ | 1..1 | Item attribute name | The name of the attribute or property of the item. | Such as “Colour”. | R28 | Text |
BT-161 | ++++ | 1..1 | Item attribute value | The value of the attribute or property of the item. | Such as “Red”. | R28 | Text |
ID | Description | Target / context | Business term / |
BR-1 | An Invoice shall have a Specification identifier (BT-24). | Process control | BT-24 |
BR-2 | An Invoice shall have an Invoice number (BT-1). | Invoice | BT-1 |
BR-3 | An Invoice shall have an Invoice issue date (BT-2). | Invoice | BT-2 |
BR-4 | An Invoice shall have an Invoice type code (BT-3). | Invoice | BT-3 |
BR-5 | An Invoice shall have an Invoice currency code (BT-5). | Invoice | BT-5 |
BR-6 | An Invoice shall contain the Seller name (BT-27). | Seller | BT-27 |
BR-7 | An Invoice shall contain the Buyer name (BT-44). | Buyer | BT-44 |
BR-8 | An Invoice shall contain the Seller postal address (BG-5). | Seller | BG-5 |
BR-9 | The Seller postal address (BG-5) shall contain a Seller country code (BT-40). | Seller Postal Address | BT-40 |
BR-10 | An Invoice shall contain the Buyer postal address (BG-8). | Buyer | BG-8 |
BR-11 | The Buyer postal address shall contain a Buyer country code (BT-55). | Buyer Postal Address | BT-55 |
BR-12 | An Invoice shall have the Sum of Invoice line net amount (BT-106). | Document totals | BT-106 |
BR-13 | An Invoice shall have the Invoice total amount without VAT (BT-109). | Document totals | BT-109 |
BR-14 | An Invoice shall have the Invoice total amount with VAT (BT-112). | Document totals | BT-112 |
BR-15 | An Invoice shall have the Amount due for payment (BT-115). | Document totals | BT-115 |
BR-16 | An Invoice shall have at least one Invoice line (BG-25). | Invoice | BG-25 |
BR-17 | The Payee name (BT-59) shall be provided in the Invoice, if the Payee (BG-10) is different from the Seller (BG-4). | Payee | BT-59 |
BR-18 | The Seller tax representative name (BT-62) shall be provided in the Invoice, if the Seller (BG-4) has a Seller tax representative party (BG-11). | Seller tax representative | BT-62 |
BR-19 | The Seller tax representative postal address (BG-12) shall be provided in the Invoice, if the Seller (BG-4) has a Seller tax representative party (BG-11). | Seller tax representative | BG-12 |
BR-20 | The Seller tax representative postal address (BG-12) shall contain a Tax representative country code (BT-69), if the Seller (BG-4) has a Seller tax representative party (BG-11). | Seller tax representative postal address | BT-69 |
BR-21 | Each Invoice line (BG-25) shall have an Invoice line identifier (BT-126). | Invoice Line | BT-126 |
BR-22 | Each Invoice line (BG-25) shall have an Invoiced quantity (BT-129). | Invoice Line | BT-129 |
BR-23 | An Invoice line (BG-25) shall have an Invoiced quantity unit of measure code (BT-130). | Invoice Line | BT-130 |
BR-24 | Each Invoice line (BG-25) shall have an Invoice line net amount (BT-131). | Invoice Line | BT-131 |
BR-25 | Each Invoice line (BG-25) shall contain the Item name (BT-153). | Item information | BT-153 |
BR-26 | Each Invoice line (BG-25) shall contain the Item net price (BT-146). | Price details | BT-146 |
BR-27 | The Item net price (BT-146) shall NOT be negative. | Item net price | BT-146 |
BR-28 | The Item gross price (BT-148) shall NOT be negative. | Price details | BT-148 |
BR-29 | If both Invoicing period start date (BT-73) and Invoicing period end date (BT-74) are given then the Invoicing period end date (BT-74) shall be later or equal to the Invoicing period start date (BT-73). | Invoicing Period | BT-74 |
BR-30 | If both Invoice line period start date (BT-134) and Invoice line period end date (BT-135) are given then the Invoice line period end date (BT-135) shall be later or equal to the Invoice line period start date (BT-134). | Invoice Line Period | BT-135 |
BR-31 | Each Document level allowance (BG-20) shall have a Document level allowance amount (BT-92). | Document level allowances | BT-92 |
BR-32 | Each Document level allowance (BG-20) shall have a Document level allowance VAT category code (BT-95). | Document level allowances | BT-95 |
BR-33 | Each Document level allowance (BG-20) shall have a Document level allowance reason (BT-97) or a Document level allowance reason code (BT-98). | Document level allowances | BT-97, BT-98 |
BR-36 | Each Document level charge (BG-21) shall have a Document level charge amount (BT-99). | Document level charges | BT-99 |
BR-37 | Each Document level charge (BG-21) shall have a Document level charge VAT category code (BT-102). | Document level charges | BT-102 |
BR-38 | Each Document level charge (BG-21) shall have a Document level charge reason (BT-104) or a Document level charge reason code (BT-105). | Document level charges | BT-104, BT-105 |
BR-41 | Each Invoice line allowance (BG-27) shall have an Invoice line allowance amount (BT-136). | Invoice line allowances | BT-136 |
BR-42 | Each Invoice line allowance (BG-27) shall have an Invoice line allowance reason (BT-139) or an Invoice line allowance reason code (BT-140). | Invoice line allowances | BT-144, BT-145 |
BR-43 | Each Invoice line charge (BG-28) shall have an Invoice line charge amount (BT-141). | Invoice line charges | BT-141 |
BR-44 | Each Invoice line charge (BG-28) shall have an Invoice line charge reason (BT-144) or an Invoice line charge reason code (BT-145). | Invoice line charges | BT-139, BT-140 |
BR-45 | Each VAT breakdown (BG-23) shall have a VAT category taxable amount (BT-116). | VAT breakdown | BT-116 |
BR-46 | Each VAT breakdown (BG-23) shall have a VAT category tax amount (BT-117). | VAT breakdown | BT-117 |
BR-47 | Each VAT breakdown (BG-23) shall be defined through a VAT category code (BT-118). | VAT breakdown | BT-118 |
BR-48 | Each VAT breakdown (BG-23) shall have a VAT category rate (BT-119), except if the Invoice is not subject to VAT. | VAT breakdown | BT-119 |
BR-49 | A Payment instruction (BG-16) shall specify the Payment means type code (BT-81). | Payment instructions | BT-81 |
BR-50 | [ANNOTATION: BY 'Fred van Blommestein' ON '2020-10-30T11:02:00'FvB NOTE: '#12']A Payment account identifier (BT-84) shall be present if Payment Type Code (BT-81) means “Credit Transfer”.A Payment account identifier (BT-84) shall be present if Credit transfer (BG-16) information is provided in the Invoice. | Account information | BT-84 |
BR-51 | The last 4 to 6 digits of the Payment card primary account number (BT-87) shall be present if Payment card information (BG-18) is provided in the Invoice. | Card information | BT-87 |
BR-52 | Each Additional supporting document (BG-24) shall contain a Supporting document reference (BT-122). | Additional supporting documents | BT-122 |
BR-53 | If the VAT accounting currency code (BT-6) is present, then the Invoice total VAT amount in accounting currency (BT-111) shall be provided. | Document totals | BT-111 |
BR-54 | Each Item attribute (BG-32) shall contain an Item attribute name (BT-160) and an Item attribute value (BT-161). | Item attributes | BT-160, BT-161 |
BR-55 | Each Preceding Invoice reference (BG-3) shall contain a Preceding Invoice reference (BT-25). | Preceding invoice reference | BT-25 |
BR-56 | Each Seller tax representative party (BG-11) shall have a Seller tax representative VAT identifier (BT-63). | Seller tax representative | BT-63 |
BR-57 | Each Deliver to address (BG-15) shall contain a Deliver to country code (BT-80). | Deliver to address | BT-80 |
BR-61 | If the Payment means type code (BT-81) means SEPA credit transfer, Local credit transfer or Non-SEPA international credit transfer, the Payment account identifier (BT-84) shall be present. | Payment instructions | BT-84 |
BR-62 | The Seller electronic address (BT-34) shall have a Scheme identifier. | Seller electronic address | BT-34 |
BR-63 | The Buyer electronic address (BT-49) shall have a Scheme identifier. | Buyer electronic address | BT-49 |
BR-64 | The Item standard identifier (BT-157) shall have a Scheme identifier | Item standard identifier | BT-157 |
BR-65 | The Item classification identifier (BT-158) shall have a Scheme identifier | Item classification identifier | BT-158 |
[ANNOTATION: BY 'Fred van Blommestein' ON '2020-10-30T11:02:00'FvB NOTE: '#14']BR-XX66 | If the invoice has one or more attachments, the attachment details shall be specified in Attached documents (BT-125) and the invoice receiver shall be warned that the processing of a structured attachment requires the knowledge of its semantics. | Attached documents | BT-125 |
[ANNOTATION: BY 'Fred van Blommestein' ON '2021-03-17T17:41:00'FvB NOTE: '#41']BR-XX67 | If Invoice line net amount (BT-131) is negative EITHER the Invoiced quantity (BT-129) shall be negative OR Invoice line allowances (BG-27) shall be greater than Invoice line charges (BG-28) plus line price (Item net price BT-146/ Item price base quantity BT-149* x Invoiced quantity BT-129).|Invoice line |BT-131. | Invoice line net amount | BT-131 |
ID | Description | Target / context | Business term / group |
BR-CO-3 | Value added tax point date (BT-7) and Value added tax point date code (BT-8) are mutually exclusive. | Invoice | BT-7, BT-8 |
BR-CO-4 | Each Invoice line (BG-25) shall be categorized with an Invoiced item VAT category code (BT-151). | Invoice Line | BT-151 |
BR-CO-5 | Document level allowance reason code (BT-98) and Document level allowance reason (BT-97) shall indicate the same type of allowance. | Document level Allowances | BT-97, BT-98 |
BR-CO-6 | Document level charge reason code (BT-105) and Document level charge reason (BT-104) shall indicate the same type of charge. | Document level Charges | BT-104, BT-105 |
BR-CO-7 | Invoice line allowance reason code (BT-140) and Invoice line allowance reason (BT-139) shall indicate the same type of allowance reason. | Invoice line Allowances | BT-139, BT-140 |
BR-CO-8 | Invoice line charge reason code (BT-145) and Invoice line charge reason (BT144) shall indicate the same type of charge reason. | Invoice line Charges | BT-144, BT-145 |
BR-CO-9 | The Seller VAT identifier (BT-31), the Seller tax representative VAT identifier (BT-63) and the Buyer VAT identifier (BT-48) shall have a prefix in accordance with ISO code ISO 3166‑1 alpha-2 by which the country of issue may be identified. Nevertheless, Greece may use the prefix ‘EL’. | VAT identifiers | BT-31, BT-48, BT-63 |
BR-CO-10 | Sum of Invoice line net amount (BT-106) = ∑shall be the sum of Invoice line net amount (BT- [ANNOTATION: BY 'Fred van Blommestein' ON '2020-11-12T10:14:00'FvB NOTE: '#2']131) with a tolerance of 0,01. | Document totals | BT-106 |
BR-CO-11 | [ANNOTATION: BY 'Sara Facchinetti' ON '2020-11-13T18:20:00'SF NOTE: '#2' NOTE: '']Sum of allowances on document level (BT-107) = ∑shall be the sum of Document level allowance amount (BT-92) with a tolerance of 0,01. | Document totals | BT-107 |
BR-CO-12 | [ANNOTATION: BY 'Sara Facchinetti' ON '2020-11-13T18:03:00'SF NOTE: '#2']Sum of charges on document level (BT-108) = ∑shall be the sum of Document level charge amount (BT-99) with a tolerance of 0,01. | Document totals | BT-108 |
BR-CO-13 [ANNOTATION: BY 'Fred van Blommestein' ON '2020-11-12T07:26:00'FvB NOTE: '#2, #8, #46'] | Invoice total amount without VAT (BT-109) = ∑ Invoice line net amount (BT-131) - Sum of allowances on document level (BT-107) + Sum of charges on document level (BT-108). | Document totals | BT-109 |
BR-CO-XXX26 | The VAT category taxable amount (BT-116) in a VAT breakdown (BG-23) shall be equal to the sum of Invoice line net amounts (BT-131) plus the sum of document level charge amounts (BT-99) minus the sum of document level allowance amounts (BT-92) where the VAT category code (BT-151, BT-102, BT-95) and the VAT rate (BT-152, BT-103, BT-96) equals the VAT category code (BT-118) and the VAT category rate (BT-119), and where applicable the exemption / out of scope reason code (BT-XXX168, BT-XXX171 and BT-XXX184) and the exemption reason text (BT-XXX167, BT-XXX170 and BT-XXX183) are identical with the VAT category exemption / out of scope reason code (BT-120) and VAT category exemption / out of scope reason text (BT-121), rounded to 2 decimals with a tolerance of 0,01. [ANNOTATION: BY 'Fred van Blommestein' ON '2020-11-12T07:41:00'FvB NOTE: '#2'] |
| |
BR-CO-XXX27 | The VAT category taxable amount (BT-116) in a VAT breakdown (BG-23) should be equal to the sum of Invoice line net amounts (BT-131) plus the sum of document level charge amounts (BT-99) minus the sum of document level allowance amounts (BT-92) where the VAT category code (BT-151, BT-102, BT-95) and the VAT rate (BT-152, BT-103, BT-96) equals the VAT category code (BT-118) and the VAT category rate (BT-119), and where applicable the exemption / out of scope reason code (BT-168, BT-171 and BT-184)(BT-XXX, BT-XXX and BT-XXX) and the exemption / out of scope reason text (BT-167, BT-170 and BT-183)(BT-XXX, BT-XXX and BT-XXX) are identical with the VAT category exemption / out of scope reason code (BT-120) and VAT category exemption / out of scope reason text (BT-121), rounded to 2 decimals. [ANNOTATION: BY 'Fred van Blommestein' ON '2020-11-12T07:41:00'FvB NOTE: '#2'] |
|
|
[ANNOTATION: BY 'Fred van Blommestein' ON '2020-11-12T07:31:00'FvB NOTE: '#8']BR-CO-XX28 | Invoice total amount without VAT (BT-109) shall be equal to the sum of VAT category taxable amounts (BT-116) | Document totals | BT-109 |
BR-CO-14 | Invoice total VAT amount (BT-110) = ∑ VAT category tax amount (BT-117). | Document totals | BT-110 |
BR-CO-15 | Invoice total amount with VAT (BT-112) = Invoice total amount without VAT (BT-109) + Invoice total VAT amount (BT-110) .)X– Amount withheld (BT-XX [ANNOTATION: BY 'Fred van Blommestein' ON '2020-11-03T14:40:00'FvB NOTE: '#29'] | Document totals | BT-112 |
BR-CO-16 | Amount due for payment (BT-115) = Invoice total amount with VAT (BT-112) - ∑ Paid amount (BT-113 [ANNOTATION: BY 'Fred van Blommestein' ON '2020-11-03T14:40:00'FvB NOTE: '#29']– ∑ Amount withheld (BT-172).+ Rounding amount (BT-114). | Document totals | BT-115 |
BR-CO-17 | VAT category tax amount (BT-117) = VAT category taxable amount (BT-116) x (VAT category rate (BT-119) / 100), rounded to two decimals. | VAT breakdown | BT-117 |
BR-CO-18 | An Invoice shall at least have one VAT breakdown group (BG-23). | VAT breakdown | BG-23 |
BR-CO-19 | If Invoicing period (BG-14) is used, the Invoicing period start date (BT-73) or the Invoicing period end date (BT-74) shall be filled, or both. | Delivery or invoice period | BT-73, BT-74 |
BR-CO-20 | If Invoice line period (BG-26) is used, the Invoice line period start date (BT-134) or the Invoice line period end date (BT-135) shall be filled, or both. | Invoice line period | BT-134, BT-135 |
BR-CO-21 | Each Document level allowance (BG-20) shall contain a Document level allowance reason (BT-97) or a Document level allowance reason code (BT-98), or both. | Document level allowance | BT-97, BT-98 |
BR-CO-22 | Each Document level charge (BG-21) shall contain a Document level charge reason (BT-104) or a Document level charge reason code (BT-105), or both. | Document level charge | BT-104, BT-105 |
BR-CO-23 | Each Invoice line allowance (BG-27) shall contain an Invoice line allowance reason (BT-139) or an Invoice line allowance reason code (BT-140), or both. | Invoice line allowance | BT-139, BT-140 |
BR-CO-24 | Each Invoice line charge (BG-28) shall contain an Invoice line charge reason (BT-144) or an Invoice line charge reason code (BT-145), or both. | Invoice line charge | BT-144, BT-145 |
BR-CO-25 | In case the Amount due for payment (BT-115) is positive, either the Payment due date (BT-9) or the Payment terms (BT-20) shall be present. | Invoice | BT-9, BT-20 |
BR-CO-26 | In order for the buyer to automatically identify a supplier, the Seller identifier (BT-29), the Seller legal registration identifier (BT-30) and/or the Seller VAT identifier (BT-31) shall be present. | Seller | BT-29, BT-30, BT-31 |
[ANNOTATION: BY 'Fred van Blommestein' ON '2020-11-06T14:12:00'FvB NOTE: '#42']BR-CO-XX29 | The Item price base quantity (BT-149) shall NOT be negative. | Price details | BT-149 |
[ANNOTATION: BY 'Fred van Blommestein' ON '2020-11-06T14:42:00'FvB NOTE: '#18, #40']BR-CO-XX30 | Invoice line net amount (BT-131) shall be equal to ((Item net price (BT-146) ÷ Item price base quantity (BT-149)) x Invoiced quantity (BT-129) + ∑ Invoice line charge amount (BT-141) – ∑ Invoice line allowance amount (BT-136) with a tolerance of 0,01. | Invoice line net amount | BT-131 |
[ANNOTATION: BY 'Fred van Blommestein' ON '2020-11-06T14:42:00'FvB NOTE: '#18, #40']BR-CO-XX31 | Invoice line net amount (BT-131) should be equal to ((Item net price (BT-146) ÷ Item price base quantity (BT-149)) x Invoiced quantity (BT-129) + ∑ Invoice line charge amount (BT-141) – ∑ Invoice line allowance amount (BT-136). | Invoice line net amount | BT-131 |
BR-CO-32 | [ANNOTATION: BY 'Sara Facchinetti' ON '2020-11-16T12:30:00'SF NOTE: '#29']If Tax withheld indicator is equal to “Yes” at Document Allowance level (BT-XXX) or Document Charge level (BT-XXX) or Line level (BT-XXX) at least one Tax withheld (BG-XX) shall be present. |
|
|
Value added tax (VAT) is an important requirement for Invoices within the European Union. The detailed requirements for VAT are governed by the European Directive VAT Council Directive 2006/112/EC of the 28th November 2006. The Directive has been adopted by member states into their respective national legislation. It should be noted that there may be variations due to legislation in each member state.
The Directive specifies who (taxable parties) and what (items and services) are liable for VAT; how the VAT is calculated; and what information shall be present in Invoices when VAT is charged in the Invoice.
The Directive also includes several exception use cases when VAT is not charged in an Invoice.
The diagram in Figure 16 illustrates a summary of the VAT Requirement Model. Different cases of VAT are identified as VAT categories and identified in a coded way. The definition of the category codes is given later in this document.
The required VAT information in an Invoice is dependent on the VAT case as detailed in 6.4.3.2 to 6.4.3.4.8. Below follows an explanation on how each VAT use case, illustrated in the diagram above, is treated in the Core Semantic Model.
In the table below the meaning of each VAT category code (based on the UNTDID 5305 code list [6]) is explained.
Definition of category | Category |
Standard VAT calculation |
|
Item is liable for VAT that is calculated in a standard way of applying the VAT percentage to the relevant taxable amount. | Standard rate |
Item is liable for VAT that is calculated in a standard way of applying the VAT percentage to the relevant taxable amount, but the VAT percentage rate is 0 (zero). | Zero rated |
VAT is not levied due to trade circumstances |
|
Item is exempt from VAT. | Exempt |
The VAT tax is not levied to an item that is liable for VAT due to trade circumstances where the Reverse charge VAT rules apply. | Reverse charge |
The VAT is not levied to an item that is liable for VAT due to trade circumstances where the rules on Intra-community supply apply. | Intra-community supply |
The VAT is not levied to an item that is liable for VAT due to trade circumstances where the rules on export outside of the EU apply. | Export |
Other VAT taxes apply |
|
Sale is subject to Canary Island (IGIC) tax. | IGIC |
Sale is subject to Ceuta and Melilla (IPSI) tax. | IPSI |
[ANNOTATION: BY 'Sara Facchinetti' ON '2020-11-10T12:59:00'SF NOTE: '#20']Sale is subject to a specific national regulation where normal VAT calculation does not apply | XX |
Not subject to VAT |
|
Sale is not subject to VAT. | Not subject to VAT |
Transferred VAT |
|
[ANNOTATION: BY 'Sara Facchinetti' ON '2020-11-10T12:59:00'SF NOTE: '#39']VAT not to be paid to the issuer of the invoice but directly to relevant tax authority (for Italian split payment) | Transferred |
For each sale, the VAT information shall be identified as follows:
— The VAT identifier of the Seller shall be stated in the Invoice;
— The VAT category code for the taxable amounts is given as Standard rate;
— The VAT category rate for the taxable amount is given as the relevant percentage rate;
— The VAT category taxable amount is the sum of Invoice line net amount minus the document level allowance amounts and plus the document level charge amounts;
— In the calculation of VAT the Invoice shall show a subtotal of the VAT taxable amount and the VAT tax amount for each VAT rate (i.e. each combination of the category code S and VAT tax rate on line level and for allowance and charges on document level).
While sale which is rated zero does not attract a VAT charge, there is, however, a requirement to state that the sale is zero rated. For each sale, recorded at Invoice line as well as document level allowances and charges the VAT shall be identified as follows.
— The VAT identifier of the Seller shall be stated in the Invoice;
— The VAT category code for the line is given as Zero rated sale;
— The VAT tax rate for the line is given as 0 percentage (zero);
— The taxable amount is the line amount;
— In the calculation of VAT, the Invoice shall show the amount taxed as zero rated as a subtotal of line amounts for lines that have VAT category code Zero rated sale;
— In the calculation of VAT, the Invoice shall show on document level the VAT charged as zero rated as the taxable amount multiplied by the percentage rate. Since by definition the rate is 0 % the VAT amount shall be zero.
ID | Description |
BR-Z-1 | An Invoice that contains an Invoice line (BG-25), a Document level allowance (BG-20) or a Document level charge (BG-21) where the VAT category code (BT-151, BT-95 or BT-102) is “Zero rated” shall contain in the VAT breakdown (BG-23) exactly one VAT category code (BT-118) equal with "Zero rated". |
BR-Z-2 | An Invoice that contains an Invoice line where the Invoiced item VAT category code (BT-151) is “Zero rated” shall contain the Seller VAT Identifier (BT-31), the Seller tax registration identifier (BT-32) and/or the Seller tax representative VAT identifier (BT-63). |
BR-Z-3 | An Invoice that contains a Document level allowance (BG-20) where the Document level allowance VAT category code (BT-95) is “Zero rated” shall contain the Seller VAT Identifier (BT-31), the Seller tax registration identifier (BT-32) and/or the Seller tax representative VAT identifier (BT-63). |
BR-Z-4 | An Invoice that contains a Document level charge where the Document level charge VAT category code (BT-102) is “Zero rated” shall contain the Seller VAT Identifier (BT-31), the Seller tax registration identifier (BT-32) and/or the Seller tax representative VAT identifier (BT-63). |
BR-Z-5 | In an Invoice line (BG-25) where the Invoiced item VAT category code (BT-151) is "Zero rated" the Invoiced item VAT rate (BT-152) shall be 0 (zero). |
BR-Z-6 | In a Document level allowance (BG-20) where the Document level allowance VAT category code (BT-95) is "Zero rated" the Document level allowance VAT rate (BT-96) shall be 0 (zero). |
BR-Z-7 | In a Document level charge (BG-21) where the Document level charge VAT category code (BT-102) is "Zero rated" the Document level charge VAT rate (BT-103) shall be 0 (zero). |
BR-Z-8 [ANNOTATION: BY 'Fred van Blommestein' ON '2020-11-12T08:07:00'FvB NOTE: '#2'] | In a VAT breakdown (BG-23) where VAT category code (BT-118) is "Zero rated" the VAT category taxable amount (BT-116) shall equal the sum of Invoice line net amount (BT-131) minus the sum of Document level allowance amounts (BT-92) plus the sum of Document level charge amounts (BT-99) where the VAT category codes (BT-151, BT-95, BT-102) are “Zero rated". |
BR-Z-9 | The VAT category tax amount (BT-117) in a VAT breakdown (BG-23) where VAT category code (BT-118) is "Zero rated" shall equal 0 (zero). |
BR-Z-10 | A VAT Breakdown (BG-23) with VAT Category code (BT-118) "Zero rated" shall not have a VAT exemption / out of scope reason code (BT-121) or VAT exemption / out of scope reason text (BT-120). |
BR-Z-11 | [ANNOTATION: BY 'Sara Facchinetti' ON '2020-11-16T17:46:00'SF NOTE: '#26']Invoice line (BG-25) where the Invoiced item VAT category code (BT-151) is "Zero rated" shall not have a Invoiced item VAT exemption / out of scope reason text (BT-XXX184) or Invoiced item VAT exemption / out of scope reason code (BT-XXX184) |
As shown in the diagram above there are situations where sales are exempted from VAT. These are cases where VAT is not levied in the Invoice.
Sales may be exempt from VAT due to various reasons in accordance to EU directives and/or national legislation. When sales are exempt from VAT for various general reasons the following information shall be given:
— the VAT identifier of the Seller shall be stated in the Invoice;
— the VAT tax category code for the line is given as Exempted from VAT;
— the VAT tax rate for each line is given as 0 (zero);
— free text description of the reason for exemption shall be given for each exempted Invoice line;
— free text description of the reason for exemption shall be given in the VAT breakdown;
— in the calculation of VAT the Invoice shall on document level show the VAT charged as zero rated as the taxable amount multiplied by the percentage rate. Since by definition the rate is 0 % the VAT amount shall be zero.
Business rules statements
ID | Description |
BR-E-1 | An Invoice that contains an Invoice line (BG-25), a Document level allowance (BG-20) or a Document level charge (BG-21) where the VAT category code (BT-151, BT-95 or BT-102) is “Exempt from VAT” shall contain exactly [ANNOTATION: BY 'Fred van Blommestein' ON '2020-11-03T13:59:00'FvB NOTE: '#9'] at least one VAT breakdown (BG-23) with the VAT category code (BT-118) equal to "Exempt from VAT": one per exemption reason (BT-120, BT-121, BT-XXX167, BT-XXX168, BT-XXX170, BT-XXX171) or one for all exemption reasons combinedBT-XXX, BT- XXX)(or one per exemption reason at line level [ANNOTATION: BY 'Fred van Blommestein' ON '2020-10-30T11:02:00'FvB NOTE: '#9'] [ANNOTATION: BY 'Sara Facchinetti' ON '2020-11-16T12:50:00'SF NOTE: '#26'] . |
BR-E-2 | An Invoice that contains an Invoice line (BG-25) where the Invoiced item VAT category code (BT-151) is “Exempt from VAT” shall contain the Seller VAT Identifier (BT-31), the Seller tax registration identifier (BT-32) and/or the Seller tax representative VAT identifier (BT-63). |
BR-E-3 | An Invoice that contains a Document level allowance (BG-20) where the Document level allowance VAT category code (BT-95) is “Exempt from VAT” shall contain the Seller VAT Identifier (BT-31), the Seller tax registration identifier (BT-32) and/or the Seller tax representative VAT identifier (BT-63). |
BR-E-4 | An Invoice that contains a Document level charge (BG-21) where the Document level charge VAT category code (BT-102) is “Exempt from VAT” shall contain the Seller VAT Identifier (BT-31), the Seller tax registration identifier (BT-32) and/or the Seller tax representative VAT identifier (BT-63). |
BR-E-5 | In an Invoice line (BG-25) where the Invoiced item VAT category code (BT-151) is "Exempt from VAT", the Invoiced item VAT rate (BT-152) shall be 0 (zero). |
BR-E-6 | In a Document level allowance (BG-20) where the Document level allowance VAT category code (BT-95) is "Exempt from VAT", the Document level allowance VAT rate (BT-96) shall be 0 (zero). |
BR-E-7 | In a Document level charge (BG-21) where the Document level charge VAT category code (BT-102) is "Exempt from VAT", the Document level charge VAT rate (BT-103) shall be 0 (zero). |
BR-E-8 [ANNOTATION: BY 'Fred van Blommestein' ON '2020-11-12T08:07:00'FvB NOTE: '#2'] | In a VAT breakdown (BG-23) where the VAT category code (BT-118) is "Exempt from VAT" the VAT category taxable amount (BT-116) shall equal the sum of Invoice line net amounts (BT-131) minus the sum of Document level allowance amounts (BT-92) plus the sum of Document level charge amounts (BT-99) where the VAT category codes (BT-151, BT-95, BT-102) are “Exempt from VAT". |
BR-E-9 | The VAT category tax amount (BT-117) In a VAT breakdown (BG-23) where the VAT category code (BT-118) equals "Exempt from VAT" shall equal 0 (zero). |
BR-E-10 | A VAT Breakdown (BG-23) with VAT Category code (BT-118) "Exempt from VAT" shall have a VAT exemption / out of scope reason code (BT-121) or a VAT exemption reason /out of scope text (BT-120). |
When VAT is not levied in an Invoice due to Reverse Charge the following data are applied in the Invoice. As both the Seller and the Buyer have an agreement to apply the reverse charge, both the Buyer and Seller shall be registered for VAT and the VAT registration numbers of both the Buyer and Seller shall be detailed in the Invoice.
Where reverse charging applies, both the Buyer and Seller shall be registered for VAT, the VAT registration numbers of both the Buyer and Seller shall be detailed in the Invoice, and the statement “reverse charge” shall be present in the invoice. An issuer of an Invoice is required to indicate when an Invoice line is a reverse charge. In the Invoice this is done by using the VAT category code for Reverse charge from code list subset of UN/TDID 5305 in relevant Invoice line.
In the electronic Invoice existence of the code for Reverse charge constitutes a declaration that the Invoice line is a reverse charge but to comply with regulation the text “Reverse charge” shall also appear in the Exemption reason / out of scope text.
The following information is given at the document level:
— the VAT identifier of the Seller;
— the VAT identifier of the Buyer;
— the text “Reverse charge” is given for the VAT exemption / out of scope reason text in the VAT breakdown (Or the equivalent standard text in other languages).
The following information shall be given on line level.
— the Invoiced item VAT category code for the line is given as Reverse charge;
— the Invoiced item VAT rate for the line is given as 0 (zero);
— the text “Reverse charge” is given for the invoiced item VAT exemption / out of scope reason text (or the equivalent standard text in other languages).
It is the responsibility of the Seller to Invoice as reverse charge when appropriate. The following rules do not verify if that decision is correct. They only check whether the information is correctly stated in the Invoice instance.
Business rules statements
ID | Description |
BR-AE-1 | An Invoice that contains an Invoice line (BG-25), a Document level allowance (BG-20) or a Document level charge (BG-21) where the VAT category code (BT-151, BT-95 or BT-102) is “Reverse charge” shall contain in the VAT breakdown (BG-23) exactly at least one VAT category code (BT-118) [ANNOTATION: BY 'Fred van Blommestein' ON '2021-02-05T11:12:00'FvB NOTE: '#26']per exemption reason (BT-120, BT-121, BT-XXX167, BT-XXX168, BT-XXX170, BT-XXX171) or one for all exemption reasons combined equal with "VAT reverse charge". |
BR-AE-2 | An Invoice that contains an Invoice line (BG-25) where the Invoiced item VAT category code (BT-151) is “Reverse charge” shall contain the Seller VAT Identifier (BT-31), the Seller Tax registration identifier (BT-32) and/or the Seller tax representative VAT identifier (BT-63) and the Buyer VAT identifier (BT-48) and/or the Buyer legal registration identifier (BT-47). |
BR-AE-3 | An Invoice that contains a Document level allowance (BG-20) where the Document level allowance VAT category code (BT-95) is “Reverse charge” shall contain the Seller VAT Identifier (BT-31), the Seller tax registration identifier (BT-32) and/or the Seller tax representative VAT identifier (BT-63) and the Buyer VAT identifier (BT-48) and/or the Buyer legal registration identifier (BT-47). |
BR-AE-4 | An Invoice that contains a Document level charge (BG-21) where the Document level charge VAT category code (BT-102) is “Reverse charge” shall contain the Seller VAT Identifier (BT-31), the Seller tax registration identifier (BT-32) and/or the Seller tax representative VAT identifier (BT-63) and the Buyer VAT identifier (BT-48) and/or the Buyer legal registration identifier (BT-47). |
BR-AE-5 | In an Invoice line (BG-25) where the Invoiced item VAT category code (BT-151) is "Reverse charge" the Invoiced item VAT rate (BT-152) shall be 0 (zero). |
BR-AE-6 | In a Document level allowance (BG-20) where the Document level allowance VAT category code (BT-95) is "Reverse charge" the Document level allowance VAT rate (BT-96) shall be 0 (zero). |
BR-AE-7 | In a Document level charge (BG-21) where the Document level charge VAT category code (BT-102) is "Reverse charge" the Document level charge VAT rate (BT-103) shall be 0 (zero). |
BR-AE-8 [ANNOTATION: BY 'Fred van Blommestein' ON '2020-11-12T08:07:00'FvB NOTE: '#2'] | In a VAT breakdown (BG-23) where the VAT category code (BT-118) is "Reverse charge" the VAT category taxable amount (BT-116) shall equal the sum of Invoice line net amounts (BT-131) minus the sum of Document level allowance amounts (BT-92) plus the sum of Document level charge amounts (BT-99) where the VAT category codes (BT-151, BT-95, BT-102) are “Reverse charge". |
BR-AE-9 | The VAT category tax amount (BT-117) in a VAT breakdown (BG-23) where the VAT category code (BT-118) is “Reverse charge” shall be 0 (zero). |
BR-AE-10 | A VAT Breakdown (BG-23) with VAT Category code (BT-118) "Reverse charge" shall have a VAT exemption reason / out of scope code (BT-121), meaning "Reverse charge" or the VAT exemption reason / out of scope text (BT-120) "Reverse charge" (or the equivalent standard text in another language). |
When VAT is not levied in an Invoice due to Intra-Community Supply the following information is included in the Invoice. As both the Seller and the Buyer have an agreement to apply the intra-community supply, both the Buyer and Seller shall be registered for VAT and the VAT registration numbers of both the Buyer and Seller shall be detailed in the Invoice.
An issuer of an Invoice is required to indicate when an Invoice line is an intra-community supply. In the Invoice this is done by using the VAT tax category code for Intra-Community from code list subset of UN/TDID 5305 in relevant Invoice line.
In the electronic Invoice the existence of the code for Intra-community supply constitutes a declaration that the Invoice line is an intra-community supply but to comply with regulation, the text “Intra-community supply” shall also appear in the Exemption / out of scope reason text.
The following information shall be given at the document level:
— the VAT identifier of the Seller;
— the VAT identifier of the Buyer;
— proof of delivery is required stating the following:
—country of delivery
—the date of delivery;
— the text “Intra-community supply” is given for the VAT exemption / out of scope reason text in the VAT breakdown (or the equivalent standard text in other languages).
The following information shall be given on line level:
— the VAT tax category code for the line is given as Intra-community supply;
— the VAT tax rate for the line is given as 0 (zero);
— the text “Intra-community supply” in the invoiced item exemption / out of scope reason text (or the equivalent standard text in other languages).
It is the responsibility of the Seller to Invoice as Intra-community Supply when appropriate. The following rules do not verify if that decision is correct. They only check whether the information is correctly stated in the Invoice instance.
Business rules statements
ID | Description |
BR-IC-1 | An Invoice that contains an Invoice line (BG-25), a Document level allowance (BG-20) or a Document level charge (BG-21) where the VAT category code (BT-151, BT-95 or BT-102) is “Intra-community supply” shall contain in the VAT breakdown (BG-23) exactly at least one VAT category code (BT-118) [ANNOTATION: BY 'Fred van Blommestein' ON '2021-02-05T11:13:00'FvB NOTE: '#26']per exemption reason (BT-120, BT-121, BT-167, BT-168, BT-170, BT-171)(BT-120, BT-121, BT-XXX, BT-XXX, BT-XXX, BT-XXX) or one for all exemption reasons combined equal with "Intra-community supply". |
BR-IC-2 | An Invoice that contains an Invoice line (BG-25) where the Invoiced item VAT category code (BT-151) is “Intra-community supply” shall contain the Seller VAT Identifier (BT-31) or the Seller tax representative VAT identifier (BT-63) and the Buyer VAT identifier (BT-48). |
BR-IC-3 | An Invoice that contains a Document level allowance (BG-20) where the Document level allowance VAT category code (BT-95) is “Intra-community supply” shall contain the Seller VAT Identifier (BT-31) or the Seller tax representative VAT identifier (BT-63) and the Buyer VAT identifier (BT-48). |
BR-IC-4 | An Invoice that contains a Document level charge (BG-21) where the Document level charge VAT category code (BT-102) is “Intra-community supply” shall contain the Seller VAT Identifier (BT-31) or the Seller tax representative VAT identifier (BT-63) and the Buyer VAT identifier (BT-48). |
BR-IC-5 | In an Invoice line (BG-25) where the Invoiced item VAT category code (BT-151) is "Intra-community supply" the Invoiced item VAT rate (BT-152) shall be 0 (zero). |
BR-IC-6 | In a Document level allowance (BG-20) where the Document level allowance VAT category code (BT-95) is "Intra-community supply" the Document level allowance VAT rate (BT-96) shall be 0 (zero). |
BR-IC-7 | In a Document level charge (BG-21) where the Document level charge VAT category code (BT-102) is "Intra-community supply" the Document level charge VAT rate (BT-103) shall be 0 (zero). |
BR-IC-8 [ANNOTATION: BY 'Fred van Blommestein' ON '2020-11-12T08:08:00'FvB NOTE: '#2'] | In a VAT breakdown (BG-23) where the VAT category code (BT-118) is "Intra-community supply" the VAT category taxable amount (BT-116) shall equal the sum of Invoice line net amounts (BT-131) minus the sum of Document level allowance amounts (BT-92) plus the sum of Document level charge amounts (BT-99) where the VAT category codes (BT-151, BT-95, BT-102) are “Intra-community supply". |
BR-IC-9 | The VAT category tax amount (BT-117) in a VAT breakdown (BG-23) where the VAT category code (BT-118) is “Intra-community supply” shall be 0 (zero). |
BR-IC-10 | A VAT Breakdown (BG-23) with the VAT Category code (BT-118) "Intra-community supply" shall have a VAT exemption / out of scope reason code (BT-121), meaning "Intra-community supply" or the VAT exemption reason / out of scope text (BT-120) "Intra-community supply" (or the equivalent standard text in another language). |
BR-IC-11 | In an Invoice with a VAT breakdown (BG-23) where the VAT category code (BT-118) is "Intra-community supply" the Actual delivery date (BT-72) or the Invoicing period (BG-14) shall not be blank. |
BR-IC-12 | In an Invoice with a VAT breakdown (BG-23) where the VAT category code (BT-118) is "Intra-community supply" the Deliver to country code (BT-80) shall not be blank. |
When VAT is not levied in an Invoice due to exports out of EU the following information is included in the Invoice.
An issuer of an Invoice is required to indicate when an Invoice line is export outside of EU. In the Invoice this is done by using the VAT tax category for Exports from code list subset of UN/TDID 5305 in the relevant Invoice line.
The following information shall be given at document level:
— the VAT identifier of the Seller;
— the text “Exports outside the EU” is given for the VAT exemption / out of scope reason text in the VAT breakdown (or the equivalent standard text in other languages).
The following information shall be given on line level:
— the VAT tax category code for the line is given as Exports;
— the VAT tax rate for the line is given as 0 (zero);
— the text “Exports outside the EU” in the Invoice line exemption / out of scope reason text (or the equivalent standard text in other languages).
It is the responsibility of the Seller to Invoice as exports when appropriate. The following rules do not verify if that decision is correct. They only check whether the information is correctly stated in the Invoice instance.
Business rules statements
ID | Description |
BR-G-1 | An Invoice that contains an Invoice line (BG-25), a Document level allowance (BG-20) or a Document level charge (BG-21) where the VAT category code (BT-151, BT-95 or BT-102) is “Export outside the EU” shall contain in the VAT breakdown (BG-23) exactly at least one VAT category code (BT-118) [ANNOTATION: BY 'Fred van Blommestein' ON '2021-02-05T11:14:00'FvB NOTE: '#26']per exemption reason (BT-120, BT-121, BT-XXX167, BT-XXX168, BT-XXX170, BT-XXX171) or one for all exemption reasons combined equal with "Export outside the EU". |
BR-G-2 | An Invoice that contains an Invoice line (BG-25) where the Invoiced item VAT category code (BT-151) is “Export outside the EU” shall contain the Seller VAT Identifier (BT-31) or the Seller tax representative VAT identifier (BT-63). |
BR-G-3 | An Invoice that contains a Document level allowance (BG-20) where the Document level allowance VAT category code (BT-95) is “Export outside the EU” shall contain the Seller VAT Identifier (BT-31) or the Seller tax representative VAT identifier (BT-63). |
BR-G-4 | An Invoice that contains a Document level charge (BG-21) where the Document level charge VAT category code (BT-102) is “Export outside the EU” shall contain the Seller VAT Identifier (BT-31) or the Seller tax representative VAT identifier (BT-63). |
BR-G-5 | In an Invoice line (BG-25) where the Invoiced item VAT category code (BT-151) is "Export outside the EU" the Invoiced item VAT rate (BT-152) shall be 0 (zero). |
BR-G-6 | In a Document level allowance (BG-20) where the Document level allowance VAT category code (BT-95) is "Export outside the EU" the Document level allowance VAT rate (BT-96) shall be 0 (zero). |
BR-G-7 | In a Document level charge (BG-21) where the Document level charge VAT category code (BT-102) is "Export outside the EU" the Document level charge VAT rate (BT-103) shall be 0 (zero). |
BR-G-8 [ANNOTATION: BY 'Fred van Blommestein' ON '2020-11-12T08:08:00'FvB NOTE: '#2'] | In a VAT breakdown (BG-23) where the VAT category code (BT-118) is "Export outside the EU" the VAT category taxable amount (BT-116) shall equal the sum of Invoice line net amounts (BT-131) minus the sum of Document level allowance amounts (BT-92) plus the sum of Document level charge amounts (BT-99) where the VAT category codes (BT-151, BT-95, BT-102) are “Export outside the EU". |
BR-G-9 | The VAT category tax amount (BT-117) in a VAT breakdown (BG-23) where the VAT category code (BT-118) is “Export outside the EU” shall be 0 (zero). |
BR-G-10 | A VAT Breakdown (BG-23) with the VAT Category code (BT-118) "Export outside the EU" shall have a VAT exemption / out of scope reason code (BT-121), meaning "Export outside the EU" or the VAT exemption / out of scope reason text (BT-120) "Export outside the EU" (or the equivalent standard text in another language). |
When a sale is not subject to VAT, the entire Invoice shall not be subject to VAT .(Directive 2006/112/EC [2], article 16, second paragraph).
Business rules statements
ID | Description |
BR-O-1 | An Invoice that contains an Invoice line (BG-25), a Document level allowance (BG-20) or a Document level charge (BG-21) where the VAT category code (BT-151, BT-95 or BT-102) is “Not subject to VAT” shall contain [ANNOTATION: BY 'Fred van Blommestein' ON '2020-11-06T13:33:00'FvB NOTE: '#10']at leastexactly one VAT breakdown group (BG-23) with the VAT category code (BT-118) equal to "Not subject to VAT": one per exemption reason (BT-120, BT-121, BT-XXX167, BT-XXX168, BT-XXX170, BT-XXX171) or one for all exemption reasons combinedor one per exemption reason at line level (BT-XXX, BT- XXX) [ANNOTATION: BY 'Sara Facchinetti' ON '2020-11-16T12:55:00'SF NOTE: '#26'] [ANNOTATION: BY 'Sara Facchinetti' ON '2020-11-16T12:50:00'SF NOTE: '#26'] . |
BR-O-2 [ANNOTATION: BY 'Fred van Blommestein' ON '2020-10-30T11:02:00'FvB NOTE: '#10, #22'] | An Invoice that contains an Invoice line (BG-25) where the Invoiced item VAT category code (BT-151) is “Not subject to VAT” shall not contain the Seller VAT identifier (BT-31), the Seller tax representative VAT identifier (BT-63) or the Buyer VAT identifier (BT-46). |
BR-O-3 [ANNOTATION: BY 'Fred van Blommestein' ON '2020-10-30T11:02:00'FvB NOTE: '#10, #22'] | An Invoice that contains a Document level allowance (BG-20) where the Document level allowance VAT category code (BT-95) is “Not subject to VAT” shall not contain the Seller VAT identifier (BT-31), the Seller tax representative VAT identifier (BT-63) or the Buyer VAT identifier (BT-48). |
BR-O-4 [ANNOTATION: BY 'Fred van Blommestein' ON '2020-10-30T11:02:00'FvB NOTE: '#10, #22'] | An Invoice that contains a Document level charge (BG-21) where the Document level charge VAT category code (BT-102) is “Not subject to VAT” shall not contain the Seller VAT identifier (BT-31), the Seller tax representative VAT identifier (BT-63) or the Buyer VAT identifier (BT-48). |
BR-O-5 | An Invoice line (BG-25) where the VAT category code (BT-151) is "Not subject to VAT" shall not contain an Invoiced item VAT rate (BT-152). |
BR-O-6 | A Document level allowance (BG-20) where VAT category code (BT-95) is "Not subject to VAT" shall not contain a Document level allowance VAT rate (BT-96). |
BR-O-7 | A Document level charge (BG-21) where the VAT category code (BT-102) is "Not subject to VAT" shall not contain a Document level charge VAT rate (BT-103). |
BR-O-8 [ANNOTATION: BY 'Fred van Blommestein' ON '2020-11-12T08:08:00'FvB NOTE: '#2'] | In a VAT breakdown (BG-23) where the VAT category code (BT-118) is " Not subject to VAT" the VAT category taxable amount (BT-116) shall equal the sum of Invoice line net amounts (BT-131) minus the sum of Document level allowance amounts (BT-92) plus the sum of Document level charge amounts (BT-99) where the VAT category codes (BT-151, BT-95, BT-102) are “Not subject to VAT". |
BR-O-9 | The VAT category tax amount (BT-117) in a VAT breakdown (BG-23) where the VAT category code (BT-118) is “Not subject to VAT” shall be 0 (zero). |
BR-O-10 | A VAT Breakdown (BG-23) with VAT Category code (BT-118) " Not subject to VAT" shall have a VAT exemption / out of scope reason code (BT-121), meaning " Not subject to VAT" or a VAT exemption / out of scope reason text (BT-120) " Not subject to VAT" (or the equivalent standard text in another language) [ANNOTATION: BY 'Fred van Blommestein' ON '2020-11-06T13:35:00'FvB NOTE: '#10']possibly with more detail. |
BR-O-11 [ANNOTATION: BY 'Fred van Blommestein' ON '2020-10-30T11:02:00'FvB NOTE: '#10'] | An Invoice that contains a VAT breakdown group (BG-23) with a VAT category code (BT-118) "Not subject to VAT" shall not contain other VAT breakdown groups (BG-23). |
BR-O-12 [ANNOTATION: BY 'Fred van Blommestein' ON '2020-10-30T11:02:00'FvB NOTE: '#10'] | An Invoice that contains a VAT breakdown group (BG-23) with a VAT category code (BT-118) "Not subject to VAT" shall not contain an Invoice line (BG-25) where the Invoiced item VAT category code (BT-151) is not "Not subject to VAT". |
BR-O-13 [ANNOTATION: BY 'Fred van Blommestein' ON '2020-10-30T11:02:00'FvB NOTE: '#10'] | An Invoice that contains a VAT breakdown group (BG-23) with a VAT category code (BT-118) "Not subject to VAT" shall not contain Document level allowances (BG-20) where Document level allowance VAT category code (BT-95) is not "Not subject to VAT". |
BR-O-14 [ANNOTATION: BY 'Fred van Blommestein' ON '2020-10-30T11:02:00'FvB NOTE: '#10'] | An Invoice that contains a VAT breakdown group (BG-23) with a VAT category code (BT-118) "Not subject to VAT" shall not contain Document level charges (BG-21) where Document level charge VAT category code (BT-102) is not "Not subject to VAT". |
In some European regions, taxes are applicable that are equivalent to VAT and need much the same processing. These taxes are in effect in the Canary Islands (IGIC) and in Ceuta and Melilla (IPSI). The following rules apply.
ID | Description |
BR-IG-1 | An Invoice that contains an Invoice line (BG-25), a Document level allowance (BG-20) or a Document level charge (BG-21) where the VAT category code (BT-151, BT-95 or BT-102) is “IGIC” shall contain in the VAT breakdown (BG-23) at least one VAT category code (BT-118) equal with "IGIC". |
BR-IG-2 | An Invoice that contains an Invoice line (BG-25) where the Invoiced item VAT category code (BT-151) is “IGIC” shall contain the Seller VAT Identifier (BT-31), the Seller tax registration identifier (BT-32) and/or the Seller tax representative VAT identifier (BT-63). |
BR-IG-3 | An Invoice that contains a Document level allowance (BG-20) where the Document level allowance VAT category code (BT-95) is “IGIC” shall contain the Seller VAT Identifier (BT-31), the Seller tax registration identifier (BT-32) and/or the Seller tax representative VAT identifier (BT-63). |
BR-IG-4 | An Invoice that contains a Document level charge (BG-21) where the Document level charge VAT category code (BT-102) is “IGIC” shall contain the Seller VAT Identifier (BT-31), the Seller Tax registration identifier (BT-32) and/or the Seller tax representative VAT identifier (BT-63). |
BR-IG-5 | In an Invoice line (BG-25) where the Invoiced item VAT category code (BT-151) is "IGIC" the invoiced item VAT rate (BT-152) shall be 0 (zero) or greater than zero. |
BR-IG-6 | In a Document level allowance (BG-20) where the Document level allowance VAT category code (BT-95) is "IGIC" the Document level allowance VAT rate (BT-96) shall be 0 (zero) or greater than zero. |
BR-IG-7 | In a Document level charge (BG-21) where the Document level charge VAT category code (BT-102) is "IGIC" the Document level charge VAT rate (BT-103) shall be 0 (zero) or greater than zero. |
BR-IG-8 [ANNOTATION: BY 'Fred van Blommestein' ON '2020-11-12T08:09:00'FvB NOTE: '#2'] | For each different value of VAT category rate (BT-119) where the VAT category code (BT-118) is "IGIC", the VAT category taxable amount (BT-116) in a VAT breakdown (BG-23) shall equal the sum of Invoice line net amounts (BT-131) plus the sum of document level charge amounts (BT-99) minus the sum of document level allowance amounts (BT-92) where the VAT category code (BT-151, BT-102, BT-95) is “IGIC” and the VAT rate (BT-152, BT-103, BT-96) equals the VAT category rate (BT-119). |
BR-IG-9 | The VAT category tax amount (BT-117) in a VAT breakdown (BG-23) where VAT category code (BT-118) is "IGIC" shall be equal to the VAT category taxable amount (BT-116) multiplied by the VAT category rate (BT-119) [ANNOTATION: BY 'Fred van Blommestein' ON '2020-11-12T10:00:00'FvB NOTE: '#2']with a tolerance of 1. |
[ANNOTATION: BY 'Fred van Blommestein' ON '2020-11-12T10:00:00'FvB NOTE: '#2']BR-IG-X | The VAT category tax amount (BT-117) in a VAT breakdown (BG-23) where VAT category code (BT-118) is "IGIC" should be equal to the VAT category taxable amount (BT-116) multiplied by the VAT category rate (BT-119). |
BR-IG-10 | A VAT Breakdown (BG-23) with VAT Category code (BT-118) "IGIC" shall not have a VAT exemption / out of scope reason code (BT-121) or VAT exemption / out of scope reason text (BT-120). |
BG-IG-11 | [ANNOTATION: BY 'Sara Facchinetti' ON '2020-11-16T17:46:00'SF NOTE: '#26']Invoice line (BG-25) where the Invoiced item VAT category code (BT-151) is "IGIC" shall not have a Invoiced item VAT exemption / out of scope reason text (BT-XXX183) or Invoiced item VAT exemption / out of scope reason code (BT-XXX184) |
[ANNOTATION: BY 'Fred van Blommestein' ON '2020-11-09T17:34:00'FvB NOTE: '#20']ID | Description |
BR-XX-1 | An Invoice that contains an Invoice line (BG-25), a Document level allowance (BG-20) or a Document level charge (BG-21) where the VAT category code (BT-151, BT-95 or BT-102) is “XX” shall contain in the VAT breakdown (BG-23) at least one VAT category code (BT-118) equal with "XX". |
BR-XX-2 | An Invoice that contains an Invoice line (BG-25) where the Invoiced item VAT category code (BT-151) is “XX” shall contain the Seller VAT Identifier (BT-31), the Seller tax registration identifier (BT-32) and/or the Seller tax representative VAT identifier (BT-63). |
BR-XX-3 | An Invoice that contains a Document level allowance (BG-20) where the Document level allowance VAT category code (BT-95) is “XX” shall contain the Seller VAT Identifier (BT-31), the Seller Tax registration identifier (BT-32) and/or the Seller tax representative VAT identifier (BT-63). |
BR-XX-4 | An Invoice that contains a Document level charge (BG-21) where the Document level charge VAT category code (BT-102) is “XX” shall contain the Seller VAT Identifier (BT-31), the Seller Tax registration identifier (BT-32) and/or the Seller tax representative VAT identifier (BT-63). |
BR-XX-10 | A VAT Breakdown (BG-23) with VAT Category code (BT-118) "XX" shall have a VAT exemption / out of scope reason code (BT-121) or VAT exemption / out of scope reason text (BT-120). |
Semantic data types are used to bridge the gap between the semantic concepts expressed by the information elements defined in the semantic model and their possible technical implementation. The semantic data types define the allowed value domain for the content, and any additional information components (attributes) needed in order to ensure its precise interpretation.
Semantic data type content may be of the following primitive types. These primitive types were taken from ISO 15000‑5:2014, Annex B.
Primitive type | Definition |
Binary | A set of finite-length sequences of binary digits. |
Date | Time point representing a calendar day on a time scale consisting of an origin and a succession of calendar [ISO 8601:2004]. |
Decimal | A subset of the real numbers, which can be represented by decimal numerals. |
String | A finite sequence of characters. |
The semantic data types described in 6.5.2 to 6.5.13 are used in the semantic data model of the core elements of an electronic Invoice, where various features such as attributes, format and decimals as well as the basic type are defined for each semantic data type. They are based on ISO 15000‑5. When used in an instance of an Invoice, each data element will contain data. In Tables 16 to 25 this is identified as the “content”. Whenever a business term is used in a core Invoice this term shall always have content and therefore the content is always mandatory.
Component | Use | Primitive Type | Example |
Content | Mandatory | Decimal | 10000.,25 |
A unit price amount states a numerical monetary amount value for data elements that contain item prices that may be multiplied by item quantities. The currency of the amount is defined as a separate business term. This EN 16931_ Unit Price_ Amount. Type is based on the Amount. Type as defined in ISO 15000‑5:2014, Annex B. EN 16931_ Unit Price_ Amount. Type is floating with no limits to the number of fraction digits
Component | Use | Primitive Type | Example |
Content | Mandatory | Decimal | [ANNOTATION: BY 'Fred van Blommestein' ON '2020-11-03T14:44:00'FvB NOTE: '#30']10000.,12345 |
Component | Use | Primitive Type | Example |
Content | Mandatory | Decimal | 10000.1234 [ANNOTATION: BY 'Fred van Blommestein' ON '2020-11-03T14:46:00'FvB NOTE: '#31']1,625 |
Component | Use | Primitive Type | Example |
Content | Mandatory | Decimal | [ANNOTATION: BY 'Fred van Blommestein' ON '2020-11-03T14:48:00'FvB NOTE: '#32']34.,7812 |
Identifiers (IDs) are keys that are issued by the sender or recipient of a document or by a third party. For each identifier in the model it is stated whether an identification scheme or a scheme version ID may or shall be defined and if so, from what list the identification schemes may be chosen. This EN 16931_ Identifier. Type is based on the Identifier. Type as defined in ISO 15000‑5:2014, Annex B. The Scheme identifier and the Scheme version ID identify the scheme on which the identifier is based.
The use of the attributes is specified for each information element in the semantic model.
Component | Use | Primitive Type | Example |
Content | Mandatory | String | abc:123-DEF |
Scheme identifier | Conditional | String | GLN |
Scheme version identifier | Conditional | String | 1.0 |
Identifiers that were assigned to a document or document line by the Buyer, the Seller or by a third party. This EN 16931_ Document Reference_ Identifier. Type is based on the Identifier. Type as defined in ISO 15000‑5:2014, Annex B.
Component | Use | Primitive Type | Example |
Content | Mandatory | String | abc:123-DEF |
Codes are used to specify allowed values in elements as well as for lists of options. Code is different from Identifier in that allowed values have standardized meanings that can be known by the recipient. This EN 16931_ Code. Type is based on the Code. Type as defined in ISO 15000‑5:2014, Annex B.
The semantic model specifies the code list to be used for each coded business term. Codes shall be entered exactly as shown in the selected code list of the applicable syntax. The latest published version of the code lists (at the time of syntax binding) shall be used.
Component | Use | Primitive Type | Example |
Content | Mandatory | String | Abc123 |
Dates shall be in accordance to the “Calendar date complete representation” as specified by ISO 8601 (see ISO 8601:2004, 5.2.1.1). Calendar dates do not include a specification for the time of the day. This EN 16931_ Date_ Date Time. Type is based on the Date Time. Type as defined in ISO 15000‑5:2014, Annex B. The content of the Date Time. Format. Text attribute is left to the syntax in which the Date is represented.
Component | Use | Primitive Type | Example |
Content | Mandatory | Date | 2015–06–10 |
Component | Use | Primitive Type | Example |
Content | Mandatory | Time | 2015–06–1014:53:44Zsshh:mm: |
Text is the actual wording of anything written or printed. This EN 16931_ Text. Type is based on the Text. Type as defined in ISO 15000‑5:2014, Annex B. Line breaks in the text may be present.
Component | Use | Primitive Type | Example |
Content | Mandatory | String | “5% allowance when paid within 30 days” |
Binary objects can be used to describe files which are transmitted together with the Invoice.
Attachments shall be transmitted together with the Invoice. There shall be only one way defined per syntax. This EN 16931_ Binary Object. Type is based on the Binary Object. Type as defined in ISO 15000‑5:2014, Annex B. EN 16931_ Binary Object. Type has two supplementary components: a Mime Code, which specifies the Mime type of the attachment and a Filename that is provided by (or on behalf of) the sender of the invoice.
Component | Use | Primitive Type | Example |
Content | Mandatory | Binary |
|
Mime Code | Mandatory | String | “image/jpeg” |
Filename | Mandatory | String | “drawing5.jpg” |
— application/pdf (.pdf);
— image/png (.png);
— image/jpeg (.jpg);
— text/csv (.csv);
— application/vnd.openxmlformats-officedocument.spreadsheetml.sheet (.xslx);
— application/vnd.oasis.opendocument.spreadsheet (.ods)
Length limitations may apply. Guidance is given in the transmission guideline CEN/TR 16931-4.
The allowed maximum number of decimals for the various business terms is specified in Table 26.
BT ID | Business term name | Allowed maximum number of decimals |
BT-166 | [ANNOTATION: BY 'Sara Facchinetti' ON '2021-02-09T17:53:00'SF NOTE: '#45']Amount to be paid | 2 |
BG-20 | DOCUMENT LEVEL ALLOWANCES |
|
BT-92 | Document level allowance amount | 2 |
BT-93 | Document level allowance base amount | 2 |
BG-21 | DOCUMENT LEVEL CHARGES |
|
BT-99 | Document level charge amount | 2 |
BT-100 | Document level charge base amount | 2 |
BG-22 | DOCUMENT TOTALS |
|
BT-106 | Sum of Invoice line net amount | 2 |
BT-107 | Sum of allowances on document level | 2 |
BT-108 | Sum of charges on document level | 2 |
BT-109 | Invoice total amount without VAT | 2 |
BT-110 | Invoice total VAT amount | 2 |
BT-112 | Invoice total amount with VAT | 2 |
BT-111 | Invoice total VAT amount in accounting currency | 2 |
BT-113 | Paid amount | 2 |
BT-114 | Rounding amount | 2 |
BT-115 | Amount due for payment | 2 |
BT-172 | Amount withheld | [ANNOTATION: BY 'Sara Facchinetti' ON '2021-02-09T17:44:00'SF NOTE: '#29']2 |
BT-173 | Withheld base amount | [ANNOTATION: BY 'Sara Facchinetti' ON '2021-02-09T17:44:00'SF NOTE: '#29']2 |
BG-23 | VAT BREAKDOWN |
|
BT-116 | VAT category taxable amount | 2 |
BT-117 | VAT category tax amount | 2 |
BG-25 | INVOICE LINE |
|
BT-131 | Invoice line net amount | 2 |
BG-27 | INVOICE LINE ALLOWANCES |
|
BT-136 | Invoice line allowance amount | 2 |
BT-137 | Invoice line allowance base amount | 2 |
BG-28 | INVOICE LINE CHARGES |
|
BT-141 | Invoice line charge amount | 2 |
BT-142 | Invoice line charge base amount | 2 |
Rules to minimize the risk of differences due to rounding as illustrated in the examples are:
— All document level totals shall be rounded to two decimals for accounting;
— Rounding shall be done on the final calculation results not on any intermediate results;
— VAT category tax amount (BT-110) shall should be rounded on document level and not as a summation of rounded Invoice line VAT amounts.
A “Core Invoice Usage Specification” (CIUS) is a specification that provides a seller with detailed guidance, explanations and examples, as well as rules (business rules) related to the actual implementation and use of structured information elements present in the core invoice model in a specific trading situation. An instance document created following a given CIUS shall always be compliant with the European Standard (this document).
Typically, a CIUS will be created by a contracting entity (buyer) in relation to its own supply chain or by a group of contracting entities wishing to achieve consistency in the way that the information elements in the core invoice model are to be used by sellers trading with an identified sector or community of buyers. The requirements set out in such a CIUS will be communicated directly to sellers or placed on a website, and may be included or referred to in the contractual documentation between the parties. Alternatively, a CIUS may be created by a group of sellers and agreed in turn by their buyer or buyers in the context of a specific industry or supply chain. A CIUS is a set of usage guidelines and/or restrictions made to the core invoice model that will still produce an invoice instance that is fully compliant with the core invoice model. That means that a receiver of an invoice document instance that has been created according to a CIUS is still able to receive and process it in accordance with the rules defined for the core invoice model.
The main reasons for developing a CIUS include:
— A receiver wishes to specify the way conditional information elements in the core invoice model are used or to restrict the content of mandatory or conditional information elements to a narrower set of requirements;
— A sender may be required to support requirements that are relevant to the trading situation. As an example, the sender may have to always provide certain information elements, even though they are specified as conditional in the core invoice model;
— a receiver requests that certain conditional elements are always used to facilitate increased automation in his processing. Examples include specified use of information elements relating to the wide variety of reference data (purchase order, contract reference, tender identifier etc.) provided in the core invoice model;
— a sender may want to explain how he applies the core invoice model to his trading information;
— a single buyer or a national and/or sectorial body may want to explain how the core invoice model is applied to given use cases. Examples of such may include use of national payment methods, the use of credit notes/negative invoices, the use of code lists and identifiers, or the use of line items. They may also wish to use terminology and language that is familiar to the targeted user;
— Another application is to restrict the information elements to those that could be included in a user-friendly e-invoice for SMEs supplying basis goods and services.
It is clearly a matter of good practice to confine the issue of a CIUS to convey essential requirements and not to proliferate their use or complexity. They should be used sparingly for justified requirements to ensure a balance between the needs of both buyer and seller.
See 4.4 for compliance rules for CIUSes.
The reference point for any CIUS is always the core invoice model as defined in this document. The specification shall clearly state in what way it creates usage guidelines or restrictions within the core invoice model.
The core invoice model is defined through the following key parameters which may be subject to further levels of specificity in a CIUS.
Business term: Business terms are used to identify an individual information element or group of information elements contained in the semantic model, and that may be exchanged in an invoice instance document. The core invoice model defines a set of business terms. Some are mandatory for the sender to include in all invoice instance documents. Others are conditional. The receiver is responsible for processing relevant information according to its processes. A CIUS may reduce the list of conditional elements or further specify their definition.
Cardinality: For each business term the core invoice model defines if it shall and how often it may appear in the same invoice instance document by stating their cardinality. A CIUS may restrict this and consequently affect how the receiver shall or can process the invoice instance document.
Semantic data type: Each business term defined in the core invoice model also has a defined semantic data type for the data it may contain. The semantic data type affects how the data shall or may be processed, as well as how it should be interpreted. For example, calculations can only be carried out using numbers, so business terms that are used in calculations are of the semantic data type number. Parties may want to further restrict the value domain of a semantic data type.
Codes and identifiers: Codes and identifiers are based on a list of schemas that define their meaning (in the case of codes) or how they are issued and structured (in the case of identifiers). For business terms that are defined as code or identifier the core invoice model specifies what code and identifier schemas may be used. In order to support specific requirements the trading partners may need to change these definitions.
Business rules: Many business terms in the core invoice model are governed by rules that control their use and content. Partner may need to change or add to these rules in order to meet specific business requirements.
Value domain for an information element: Only in few cases does the core invoice model define value domains or the format of the data. Trading partners may want to prescribe such rules where there are none or to restrict existing ones to support specific requirements. For example the core invoice model does in some cases restrict allowed values to non-negative. On the other hand it does not set restrictions on text lengths, which may be included in a CIUS.
7.3.2 lists in more detail the type of specification that can be made in a CIUS based on the core invoice model and set out in a bilateral agreement between the trading parties.
Trading parties may make the following specifications within the core invoice model and the resulting invoice instance will still be compliant with the core invoice model and as result a receiver can process the invoice without any modification to his processing. However, the recipient may choose to take advantage of the specifications defined in the CIUS to further streamline his invoice processing.
Type of change | Example/remark |
Business Terms |
|
Mark conditional Information element not to be used | Can be achieved by changing cardinality 0..x to 0..0. This essentially means that an element which use is conditional is not to be used. This will not affect the receivers processing. Care need to be taken to ensure that the business rules defined for the core invoice model are not broken. |
Make semantic definition narrower | A narrower semantic definition of a business term means that the meaning conveyed is still within the meaning defined in the core invoice model and is already recognized by the receiver. |
Add synonyms | As synonyms will only supplement the original business terms but do not replace it - the original term is still normative. A receiver who has designed his processing based on the core invoice model can continue to do so. Examples of synonyms are mapping of national or sector terminology to the terminology used in the core invoice. |
Add explanatory text | Adding explanatory text that, for example, explains how a business term is used in a specific use case. There is a risk that such text may also affect the semantic definition and this shall be avoided. Explanatory information does not require any further action from the receiver and the automatic processing of the assigned invoice is still possible. |
Cardinality |
|
Make a conditional element mandatory (0..x – > 1..x) | If a conditional element is made mandatory it simply means that the option of using it is applied. The receiver shall be prepared for the situation that a conditional element is used, so he does not need to modify his processing. |
Decrease number of repetitions (x..n – > x..1) | If the number of repetitions is decreased they will remain within the limit that the receiver has catered for. |
Semantic data type |
|
Change semantic data type from string to ... | If the semantic data type of a business term is changed from string to some other type the receiver can still process the value as a string. |
Codes and identifiers |
|
Remove one of multiple defined lists | Where the core invoice semantic model defines more than one allowed list and the core invoice usage specification reduces the number of allowed lists then the invoice instance document is still compliant. However such a change shall leave at least one of the defined lists in place. |
Mark defined values as not allowed | If the allowed code values are restricted within an existing list it simply means that certain values of the full list are being used and the receiver should have designed for processing them. |
Business Rules |
|
Add new non-conflicting business rule for existing element(s) | Represents an additional restriction on the allowed content within what is defined for the core invoice model. The receiver should therefore have designed for that content. |
Make an existing business rule more restrictive | The exchanged content of the business term remains within what was defined for the core invoice model and the receiver should have designed for it. |
Value domain for an element |
|
Restrict text or byte array length | If a maximum is set on the length where there was no limit the content remains within what was defined for the core invoice model. |
Require defined structured values | When the core invoice model does not set a structure on a value the receiver would not have designed for processing in any particular form. Rules to enforce a given pattern should therefore not affect his processing. |
Restrict allowed fraction digits | Fewer fraction digits result in a value that is within the accuracy that the receiver would have designed for when implementing the core invoice model. |
A CIUS shall always be documented with clear reference to the core invoice model. It may be documented either as changes only, or as a full specification. If documented as a full specification, it shall be clear in what way the specification differs from its underlying specification and represents a further specification within the core invoice model.
Core invoice usage specifications should be documented in an appropriate repository for retrieval and sharing. The availability of such a repository is expected to foster convergence over time.
Agreement between Buyers and Sellers on using a core invoice usage specification should be part of the commercial contract between them.
A CIUS is implemented through a syntax and each specification may be mapped to one or more syntaxes.
For clarity and to avoid confusion the general rules should be that a CIUS should have the same “look and feel” and use identical notation and terminology as is used for the core invoice model itself.
Specifications and restrictions documented in a CIUS shall be mapped to the relevant syntax in accordance to the same syntax binding methodology as is used for the core invoice model -see CEN/TS 16931-3-1.
For clear referencing and identification in processing each CIUS and its version shall be clearly identified and have an assigned identifier.
The invoice instance document itself should carry the assigned identifier in the business term “Specification identification”. This will allow the receiver of the invoice instance document to apply processing of the document in accordance with the rules under which it was generated.
A
(informative)
Assessment of the compliance of the European Standard with the requirements of the Standardization Request of the European Commission
Directive 2014/55/EU (the Directive) on electronic invoicing in public procurement aims at facilitating the use of electronic invoices by economic operators when supplying goods, works and services to the public sector. In particular, it sets out the legal framework for the establishment of a European standard (EN) for the semantic data model of the core elements of an electronic invoice.
The EN as presented is respectfully submitted as fully meeting the requirements of the Standardization Request in relation to those relating to the semantic model. Each issue raised in the Standardization Request has been set out below and then assessed as to whether and how it is resolved in the EN.
It should first be noted that the Directive builds on a Recommendation of the European Multi-Stakeholder Forum on e-Invoicing on the use of a semantic data model to support the interoperability for electronic invoicing, issued on 1 October 2013. This Recommendation states that an invoice is considered to be composed of a number of distinct sections:
– The Core Section contains the basic information elements (i.e. the core elements referred to in the Directive) required to exchange electronic invoices between all types of trading entities (covering the basic needs of cross-border and cross-sector e-invoicing). It consists of a Legal Part plus a Common Part. The Legal Part is concerned with both the observance of tax and commercial laws and regulations pertaining to invoicing commonly in force throughout the EU. The Common Part contains commonly used and accepted commercial information elements, which are not sector or country specific.
– The Sector Section contains those information elements which are only a concern of a specific industry sector, community, supply chain or buyers and sellers of a particular type of product. Such information elements may be incorporated in an invoice as an ’Extension’ to the Core Section information elements.
– The Country Section contains information elements or further information about such information elements, which represent the specific requirements of a particular Member State above and beyond the Core Section information elements
The Recommendation proposed to formalize the semantic data model of the core section of an electronic invoice in a European standard. This suggestion has to a large degree been taken into account. The Directive calls for the development of a European standard which defines the core elements of the invoice, while at the same time requesting guidelines on the use of the Country and Sector extensions.
It shall be stressed that, in line with the Directive, all contracting authorities and contracting entities in the EU will be obliged to receive and process an e-invoice as long as it contains the required core elements of an invoice defined in this document (and provided that it is represented in any of the syntaxes specified in CEN/TS 16931-2. The inclusion of any information which is not contained in this core will be at the sender’s discretion. As such, any Country or Sector extension in an e-invoice shall by definition be optional.
The EN has been designed to ensure that all legally required information elements at country level are capable of being addressed in the Core Invoice Model of the EN. The Extension Methodology has been designed to allow trading parties to capture requirements for additional information elements and for these to be reflected in an invoice instance according to rules established in the Extension Methodology and by the parties to a particular Extension Specification. Whilst always optional, the use of an Extension may be subject to contractual conditions between the parties. Trading Parties may also use a Core Invoice Usage Specification to specify ways in which the Semantic Model is to be applied in a given trading situation, granted the various choices and cardinalities that exist. All these tools should ensure that the use of the EN can be flexibly applied to the needs of buyers and sellers
The following subclauses set out a number of requests that are embedded in the Standardization Request. Each is defined, discussed and a response provided as to how the EN reflects the requirement. The requirements are grouped into three categories: requirements arising from a number of identified EU projects, those arising from specific requirements and those arising from ESO (European Standards Organization) requirements. Relevance and Risk ratings have been assigned to these requirement (see page 15-16).
ID | Standardization Request Item | Relevance | Risk | Conclusion | |||||
1.1 | Standardization Request Text: | LOW | LOW | MET | |||||
| The work should take into account the European Interoperability Framework (EIF), and the interoperability solutions created under the ISA programme.’ | ||||||||
1.1.1 | Discussion | ||||||||
| Based on its knowledge of the EIF4, CEN/TC 434 agreed in advance that a reactive approach should be taken with respect to the specific recommendations of the EIF, with the framework being considered as a point of reference and taken into account as and when the TC encountered potentially serious issues which appeared to be impacted. No such issues came to light during the work. | ||||||||
1.1.2 | Assessment of the draft EN with respect to this Standardization Request requirement | ||||||||
| Based on TC434 task force’s knowledge and the high level nature of the vision expressed in the EIF, whose philosophy has already been embedded in much recent standardization work such as in the source standards for the EN, no specific further requirements for the EN were anticipated to be necessary. The EN is fully aligned with the EIF. | ||||||||
ID | Standardization Request Item | Relevance | Risk | Conclusion | |||||
1.2 | Standardization Request Text: | MEDIUM | MEDIUM | MET | |||||
| The new Regulation on electronic identification and trust services (e-IDAS) for electronic transactions in the internal market with due respect to its date of entry into force. | ||||||||
1.2.1 | Discussion | ||||||||
| Where used by trading parties, advanced electronic signatures or seals are relevant to the EN as by definition, they uniquely identify and link its signatory or seal creator to the content (authenticity of origin) and will invalidate the signature or the seal if the signed data has been tampered with (integrity of data). Advanced electronic signatures or seals can be technically implemented as described in Commission Implementing Decision (EU) 2015/1506 of 8 September 2015 laying down specifications relating to formats of advanced electronic signatures and advanced seals to be recognized by public sector bodies pursuant to Articles 27(5) and 37(5) of eIDAS Regulation. It establishes that XAdES, PAdES, CAdES and the associated containers shall be supported by Member States. The signature or the seal should always be applied to the transmitted payload so that the authenticity and integrity of the invoice can be verified during the whole legal archiving period and for confidentiality purposes. At the message or header level, the transmitted message could be also signed or sealed (e.g. when sent using the AS2 protocol), for the whole or during a stage or stages of the transmission process, but the use of signatures or seals in these circumstances is separate from its use to ensure authenticity and integrity. The requirements of the e-IDAS Regulation as stated above are important in the transmission layer for invoice delivery and for archiving purposes. They have no impact on invoice content as defined in the EN. | ||||||||
1.2.2 | Assessment of the draft EN with respect to this Standardization Request requirement | ||||||||
| There are no implications for the Semantic Data Model for the draft EN arising from the e-IDAS Regulation. | ||||||||
ID | Standardization Request Item | Relevance | Risk | Conclusion | |||||
1.3. | Standardization Request Text: | MEDIUM | MEDIUM | MET | |||||
| The results of Large Scale Pilot (LSP) projects implemented within the framework of the ICT Policy Support Programme (ICT-PSP) under the umbrella of the Competitiveness and Innovation Framework Programme (CIP). | ||||||||
1.3.1 | Discussion | ||||||||
| Liaisons were established with the LSP projects and relevant experts participated in the work of CEN/TC 434. | ||||||||
1.3.2 | Assessment of the draft EN with respect to this Standardization Request requirement | ||||||||
| No issues came to light as a result of the above-mentioned liaisons. | ||||||||
ID | Standardization Request Item | Relevance | Risk | Conclusion | |||||
1.4 | Standardization Request Text: | MEDIUM | MEDIUM | MET | |||||
| The Digital Service Infrastructure (DSI) on e-invoicing to be deployed in the framework of the Connecting Europe Facility (CEF). | ||||||||
1.4.1 | Discussion | ||||||||
| Liaisons were established with the CEF programme and ongoing discussion took place through CEF participation in the work of CEN/TC 434. | ||||||||
1.4.2 | Assessment of the draft EN with respect to this Standardization Request requirement | ||||||||
| Since the CEF DSI e-invoicing initiative is a rolling effort fully supportive of the EN, and is not focused on standards design, no impact is foreseen. | ||||||||
| ID | Standardization Request Item | Relevance | Risk | Conclusion |
| 2.1a | Standardization Request Text: | HIGH | MEDIUM | MET |
|
| The EN should be technologically neutral | |||
| 2.1a.1 | Discussion | |||
|
| Technological neutrality requires that the EN should be capable of being expressed and used in any ICT (information and communications technology) environment, both presently available and foreseeably extending into the reasonable future. The EN will be rendered in a number of syntaxes and should also be capable of being carried in a container or envelope both as a structured message and as a human readable presentation. Since such an invoice, i.e. one that is compliant with the EN may carry confidential information it should be capable of encryption. The latter is considered not to compromise neutrality of approach in relation to technical solutions. It is clearly a very important requirement as without technological neutrality, the EN will not be widely adopted. | |||
| 2.1a.2 | Assessment of the draft EN with respect to this Standardization Request requirement | |||
|
| The requirement has been met- nothing in the EN design dictates that a particular technology is used for the creation, delivery or processing of an electronic invoice based on the EN. | |||
| ID | Standardization Request Item | Relevance | Risk | Conclusion |
| 2.1b | Standardization Request Text: | HIGH | MEDIUM | MET |
|
| The EN should be commercially neutral | |||
| 2.1b.1 | Discussion | |||
|
| Commercial neutrality entails that electronic invoices which comply with the EN: May be Used in any commercial situation involving any trading party May be delivered directly from one trading party to another, or be the subject of a processing and delivery service provided by an intermediary service organization. Do not dictate the commercial model underlying the supply of goods and services itself, or the commercial model in the provision of intermediary delivery or processing services These principles should be supported and all commonly encountered scenarios for commercial models should not be impeded. This is clearly a very important requirement as without commercial neutrality, the EN will not be widely adopted. | |||
| 2.1b.2 | Assessment of the draft EN with respect to this Standardization Request requirement | |||
|
| The requirement has been met- nothing in the EN design dictates the commercial model that underlies a supply of goods and services or the creation, delivery or processing of an electronic invoice based on the EN. | |||
| ID | Standardization Request Item | Relevance | Risk | Conclusion |
| 2.2 | Standardization Request Text: | HIGH | LOW | MET |
|
| The EN should be compatible with relevant international standards on e-invoicing | |||
| 2.2.1 | Discussion | |||
|
| The semantic data model for the core elements of an e-invoice should be based on relevant commercial and technical specifications such as BII and MUG and should take into account other international standards such as: CII XML V2 and v3 UBL 2.1 Financial Invoice other formats (e.g. EDIFACT) other relevant technical specifications This requirement was embedded in the work of TC 434 as a key deliverable and reflected in project organization and methodology. | |||
| 2.2.2 | Assessment of the draft EN with respect to this Standardization Request requirement | |||
|
| The requirement has been met as the EN is essentially based on the above-mentioned standards with suitable evolution. Other international standards and specifications for particular components such as Code Lists were referenced as required. | |||
| Id | Standardization Request Item | Relevance | Risk | Conclusion |
| 2.3 | Standardization Request Text: | MEDIUM | MEDIUM | MET |
|
| Have regard to the need for personal data protection in accordance with Directive 95/46/EC, to a ‘data protection by design’ approach and to the principles of proportionality, data minimization and purpose limitation | |||
| 2.3.1 | Discussion | |||
|
| This request is designed to ensure that the draft EN will support and certainly not impede present and emerging Data Protection requirements. The requirements of the Data Protection Frame work in the EU have been taken into account. | |||
| 2.3.2 | Assessment of the draft EN with respect to this Standardization Request requirement | |||
|
| There are no known impacts of regulatory requirements for personal data protection that negatively impact the Semantic Data Model. The design approach taken has been proportionate, based on required data only and does not take the core invoice model outside its essential and necessary purpose. Facilities exist for encrypting relevant data and required personal ‘party’ information is of a ‘business card’ nature only. | |||
| Id | Standardization Request Item | Relevance | Risk | Conclusion |
| 2.4 | Standardization Request Text: | HIGH | MEDIUM | MET |
|
| be compatible with Directive 2006/112/EC, and suitable for use with non-VAT invoices | |||
| 2.4.1 | Discussion | |||
|
| In addition to leveraging VAT expertise in CEN/TC 434, the work included consultation with VAT experts to identify and ensure all the requirements of VAT and non-VAT invoices are covered. Where local taxes have characteristics essentially similar to VAT, those information elements have been used to express such taxes. Where other charges, imposts and other taxes are required they are handled at the line level in the core invoice model. | |||
| 2.4.2 | Assessment of the draft EN with respect to this Standardization Request requirement | |||
|
| Completed and verified. | |||
| Id | Standardization Request Item | Relevance | Risk | Conclusion |
| 2.5 | Standardization Request Text: | HIGH | MEDIUM | MET |
|
| allow the establishment of practical, user-friendly, flexible and cost-efficient electronic invoicing systems | |||
| 2.5.1 | Discussion | |||
|
| All public sector contracting entities in the EU will be required to ‘receive and process electronic invoices which comply with the EN and with any of the identified syntaxes which comply with the EN’. Consequently, the EN supports the invoicing requirements of the whole universe of public bodies and their suppliers, including those not currently familiar with the use of electronic invoicing. This also applies to private sector buyers and their suppliers. Based on the provisions of Directive 2014/55/EU, a contracting public authority or entity (including smaller and sub-central public authorities) will be required to support the receipt and processing of an e-invoice based on the European standard. It is preferable in the interests of cost saving and efficiency that contracting authorities adopt automated processing to the maximum extent feasible and where appropriate will no doubt consider the use of shared service models. To meet the above requirements, the focus needs to be on facilitating the development of systems involved in automating B2G and B2B electronic invoicing, either on a stand-alone basis, or as part of end to end e-Procurement systems - including the handling of domestic and cross-border transactions. Examples of applicable systems include Enterprise Resource Planning (ERP) and workflow systems, e-invoicing service provider platforms of all types, B2B networks, e-invoices delivered under a direct B2B model, and EDI systems. Any system that can create, deliver or process an electronic invoice in the context of a supply chain should be able to handle the EN in a way that encourages adoption, including the provision of standard implementation guidelines and user instructions. The providers of the above-listed e-invoicing systems and services include those provided by service and solution providers and those operated in-house by enterprises. The EN should be capable of being used by all such e-invoicing systems and platforms, which see a benefit in adopting the EN. If adoption by e-invoicing systems is not well supported or encouraged the adoption rate will be significantly affected. The Commission’s goal of e-invoicing being the predominant method by 2020 will be at risk. | |||
| 2.5.2 | Assessment of the draft EN with respect to this Standardization Request requirement | |||
|
| Whilst this requirement has been in the mind of CEN/TC 434 throughout the design process, it is recognized that at various stages of the design, testing and implementation process, external input needs to be gathered from sources external to TC434 to provide a full assessment. To ensure that this requirement has high probability of being met, TC 434 established a set of evaluation criteria which was included in a survey during the public inquiry phases of the CEN/TC 434 project to obtain feedback on the dimensions of practicality, and ease of use in relation to implementation of the EN. The results of this survey were somewhat inconclusive perhaps because the EN was still in the formative stage; some respondents were convinced on this point but others felt that it was too early to tell. Further efforts over time will be required to confirm all of the above-mentioned criteria, especially by contracting entities. It should be stated, however, that since the semantic data model is based on existing well used standards, there is no reason to expect a negative outcome with regard to this Standardization Request. This conclusion does not include the syntax aspect, which is the subject of separate assessment. A key source of information will be the output of Work Stream 8 (test results and methodologies), which will also address the issue of ensuring that the draft EN is simple and easy to use and support. | |||
| Id | Standardization Request Item | Relevance | Risk | Conclusion |
| 2.6 | Standardization Request Text: | HIGH | MEDIUM | MET |
|
| take into account the special needs of small and medium-sized enterprises as well as of sub-central contracting authorities and contracting entities | |||
| 2.6.1 | Discussion | |||
|
| In using the Semantic Data Model, SMEs require ease of use and cost effectiveness. This means that the perceived cost and resource implications of adopting a solution based on the new standard should be less than or equal to their existing system, which may be paper based. Ease of use is vital as there will not necessarily be a requirement for SMEs to use EN compliant electronic invoicing only an enticement, except in situations where contracting authorities mandate its use. It will be vital for SMEs to ensure the provision by contracting authorities or their service providers of invoice data/invoice capture systems that as far as possible shield the SME from the implementation of the technical aspects of the core invoice model. It should also be possible to create EN compliant e-invoices that can be easily made presentable in a human readable format such as a PDF or a printed paper document. The EN has been designed to support the needs of SMEs and smaller contracting authorities. The CEN TC 434TC 434 has engaged in a process to balance the need for potential richness of functionality against the criteria for ease of use. This has been a deliberate process. The Semantic Data Model confines itself to the information elements that are strictly necessary (at least in relation to mandatory elements). This will ensure a simple model which can be easily adopted by processing systems. The model has been contained within reasonable boundaries without too much functionality embellishment. The development of the Core Invoice Usage Specification as a tool for use by trading parties holds the key to ensuring ease of use by SMEs and smaller contracting entities. Such a specification issued by a contracting entity allows the content of the invoice in a specific trading context to be confined to a selection of information elements including those required on a mandatory basis together with other commonly required elements, so as to suit the needs and capabilities of smaller trading parties. The degree of optionality and cardinality in the semantic data model supports such a tailoring process. It is further expected that SMEs are unlikely to participate in invoice extensions to any substantial extent. | |||
| 2.6.2 | Assessment of the draft EN with respect to this Standardization Request requirement | |||
|
| To ensure that the needs of SMEs and smaller contracting entities will be met, TC 434 established a set of evaluation criteria which was included in a survey during the public inquiry phase of the CEN/TC 434 project to obtain feedback on the dimensions of ease of use in relation to implementation of the EN. The results of this survey were somewhat inconclusive perhaps because the EN was still in the formative stage; some respondents were convinced on this point but others felt that it was too early to tell. Further efforts will be required over time to confirm all of the above-mentioned criteria. Work Stream 8 (test results and methodologies) should also ensure that the EN is simple and easy to use. The importance of appropriate use of the Core Invoice Usage Specification has already been stressed above. It should also be recognized that support for smaller entities is not just a matter for the design of the semantic data model; it is also dependent on the existence in the wider eco-system of tools and services aimed at serving the needs of these entities. | |||
| Id | Standardization Request Item | Relevance | Risk | Conclusion |
| 2.7 | Standardization Request Text: | MEDIUM | LOW | MET |
|
| not require, and not impede, the use of electronic signatures or seals | |||
| 2.7.1 | Discussion | |||
|
| The EN should not require the use of electronic signatures or seals, nor prevent their use. Neutrality is important. It is important to ensure that the draft EN design is neutral as to the use of electronic signatures and seals, and their presence, if used, does not have an impact on invoice content. In the unlikely event that the project did not observe this requirement it would limit usage. | |||
| 2.7.2 | Assessment of the draft EN with respect to this Standardization Request requirement | |||
|
| Since electronic signatures and seals are not an intrinsic part of the invoice content represented by the standardized e-invoice represented by the EN, this requirement will not be a hurdle. E-Signatures and Seals, if used, are added subsequent to invoice creation and this aspect is explained in the Guidelines at the Transmission level, another deliverable of CEN/TC 434. | |||
| Id | Standardization Request Item | Relevance | Risk | Conclusion |
| 2.8 | Standardization Request Text: | MEDIUM | LOW | MET |
|
| The Draft EN should contain an informative annex which provides a clear, transparent and precise indication of the relationship between the elements of the EN and the corresponding EU legal requirements specified in this standardization request | |||
| 2.8.1 | Discussion | |||
|
| The need to publish this informative annex is well understood and supported. | |||
| 2.8.2 | Assessment of the draft EN with respect to this Standardization Request requirement | |||
|
| CEN PC434 has prepared the informative annex containing the comparison with appropriate legal support. This is considered to be an important due diligence process. | |||
| Id | Standardization Request Item | Relevance | Risk | Conclusion |
| 2.9 | Standardization Request Text: | HIGH | MEDIUM | MET |
|
| Should help to preserve investments already made at national level | |||
| 2.9.1 | Discussion | |||
|
| The requirement has the purpose of ensuring that the stakeholders affected by the EN will not render existing investments in e-invoicing redundant or incapable of continued operation, especially those already operating at a national level, or those operating more widely. Of course, where existing investments are not worthy of preservation, market forces will usually trigger their demise. Realism is required. It is already clear that Member State contracting authorities are quite free to continue to use existing systems and standards that have already been implemented. There should be no doubt about this so as to avoid a freeze on market development until the standard is deployed. The following points have been taken into consideration in designing the semantic data model: Given its basic similarity to other already used e-invoicing standards, the EN can be implemented in existing systems without significant impact. The semantic data model does not add functionality not already largely present in such existing standards. It will be possible to incorporate the EN into existing solutions based on widely available mapping tools. | |||
| 2.9.2 | Assessment of the draft EN with respect to this Standardization Request requirement | |||
|
| It is considered that the Draft EN has taken full cognisance of the issues raised above. The requirement has been met by basing the design of the semantic data model on previous work done (MUG and CEN BII being the main sources) and by ensuring that current e-invoicing specifications and standards used in the Member States that have implemented the mandatory use of e-Invoicing have been referenced and considered as input to the work. The issue, however will be ongoing and the following actions are proposed as follow-up initiatives: Guidelines and information about the EN: There will be a need to develop and issue information and guidelines including model checklists and recommendations on how to implement the EN in existing national level solutions. The actual content of the guidelines will obviously need to be elaborated and detailed covering both the EN and the syntax implementation. Semantic model: the semantic model itself needs to be well documented with an implementation perspective particularly in the context of existing national systems. Survey required: organizations providing existing national level solutions should be questioned and asked to present an assessment of the expected effort to implement the EN and its supported syntaxes. | |||
| Id | Standardization Request Item | Relevance | Risk | Conclusion |
| 2.10 | Standardization Request Text: | HIGH | LOW | MET |
|
| include the physical and financial supply chain perspective, i.e. not treat the invoice in isolation but consider related trade and finance documents19 and processes (e.g. reconciliation, supply chain finance, credit notes, etc.), and reflect both private and public sector requirements, with a view to allowing the full straight-through processing (STP) of an electronic invoice | |||
| 2.10.1 | Discussion | |||
|
| An invoice does not exist in isolation but forms part of a chain of events and processes. The physical supply chain (PSC) describes the system of organization, people, activities, information, and resources involved in moving a product or service from supplier to buyer. Supply chain activities transform raw materials, intellectual property and components into a finished product or service that is delivered to the final buyer. The financial supply chain (FSC) refers to the risk management practices and transactions that facilitate the purchase (procurement) of, and payment for, goods and services, such as concluding contracts, exchanging purchase orders and invoices, managing liquidity, raising working capital finance, and making payments. | |||
|
| The most important factor in ensuring that the invoice plays its pivotal role in the PSC and FSC is its use of reference information that links it unambiguously to both preceding and subsequent supply chain events such as the procurement process, the delivery process, and subsequent financing and payments. A set of sufficient reference fields with definitions have been identified and included in the semantic data model. These references will support two and three-way matching processes for both internal control/reconciliation, and for demonstrating that the trading party’s business process controls support the authenticity and integrity of the transaction for fiscal purposes. The needs of the procurement {or e-Procurement) process have been included including references such as purchase order and despatch advices, delivery notes etc. Particular attention has been paid to the needs of the public sector to receive specific references for contracts, public tenders and other means to ensure control over public expenditure. | |||
|
| Particular attention has also been paid to the requirement that an invoice or group of invoices should be unambiguously identified by means of remittance information that can accompany an electronic payment linked to that invoice or group of invoices. The payment aspect of invoicing will be fully supported. The model caters for standing instructions where the payment details are held by the buyer separately in a secure database and not referred to in the body of the invoice. It also caters for payment instructions embedded in a single invoice and referring to: payment instrument, institution, account numbers and routing information as required. CEN/TC 434 took steps to refer all such payment aspects to the European Payments Council for review. The needs of the factoring industry engaged in invoice finance have also been taken into account. | |||
|
| All selected references will permit the straight-through-processing of transactions through a supply chain in the systems of both the trading parties and any related service providers, including timely reconciliation. Credit Notes and negative value invoices are also included. The approach taken has reflected the potential for a reasonable level of automation- and not to a level of perfection where costs outweigh benefits. There is a reasonable balance in meeting the needs of contracting entities, whether in the public or private sector, and the needs of suppliers of all sizes in managing their supply chain activities. | |||
| 2.10.2 | Assessment of the draft EN with respect to this Standardization Request requirement | |||
|
| It is considered that the Draft EN has taken full cognisance of the issues raised above. In particular, it is clearly the case that a rich set of reference information elements have been provided in the EN covering all stages of the physical and financial supply chain. | |||
| Id | Standardization Request Item | Relevance | Risk | Conclusion |
| 2.11 | Standardization Request Text: | HIGH | MEDIUM | MET |
|
| be suitable for voluntary use in commercial transactions between enterprises and have the capacity to reflect specific needs and requirements of the business-to-business (B2B) ecosystem | |||
| 2.11.1 | Discussion | |||
|
| As a core invoice EN, the data set should apply equally to both public and private sector transactions and there should be no difference between the two. If private sector requirements were not to be incorporated the adoption of the EN will be limited to public sector use and suppliers will be faced with ‘silos’. The Core Invoice Usage Specification tool incorporated into the design gives an important flexibility to contracting entities in both the public and private sectors. Any additional requirements of both public sector and private sector trading communities have been reflected in the Extension methodology. The semantic data model has a wide variety of both ‘mandatory’ and ‘optional’ information elements. To the maximum extent possible, the information elements use established international standards and practices for items like dates, units of measure etc. and appropriate code lists. Where appropriate such items should be repeating elements based on a standard approach. Buyer and supplier references such as cost centres and other codes should be catered for to a reasonable extent. These features will suit private sector entities already familiar with such data practices. The semantic data model will support processes at sender, service provider and buyer level to validate the invoice and establish compliance with fiscal and other requirements. There should be sufficient line level detail in the invoice to support the operations of the trading parties. | |||
| 2.11.2 | Assessment of the draft EN with respect to this Standardization Request requirement | |||
|
| It is considered that the Draft EN has taken full cognisance of the issues raised above. | |||
Id | Standardization Request Item | Relevance | Risk | Conclusion | |
2.12 | Standardization Request Text: | LOW | LOW | MET | |
| be re-usable in other standardization initiatives | ||||
| 2.12.1 | Discussion | |||
|
| Re-usability in other standardization initiatives is a rather wide and unspecific requirement. As the EN has been developed based on a strong methodology using well accepted information elements and components, the reusability (for example to create a standard purchase order) should be facilitated | |||
| 2.12.2 | Assessment of the draft EN with respect to this Standardization Request requirement | |||
|
| It is considered that this requirement whilst important has had a low impact on the project. The EN has taken full cognisance of the issues raised above. | |||
| Id | Standardization Request Item | Relevance | Risk | Conclusion |
| 2.13 | Standardization Request Text: | HIGH | LOW | MET |
|
| The EN should contain, inter alia, the elements mentioned in Article 6 of the Directive 2014/55/EU. | |||
| 2.13.1 | Discussion | |||
|
| The Article 6 requirements need to be taken into account as a fundamental requirement | |||
| 2.13.2 | Assessment of the draft EN with respect to this Standardization Request requirement | |||
|
| This requirement has been fully met. | |||
Id | Standardization Request Item | Relevance | Risk | Conclusion | ||
3.1 | Standardization Request Text: | MEDIUM | LOW | MET | ||
| The European standard (EN) and the ancillary deliverables described above shall take due account of any relevant material developed (or which will be developed in future) by the European Multi-Stakeholder Forum on e-Invoicing. | |||||
| 3.1.1 | Discussion | ||||
|
| It is essential that close cooperation and cross representation with EMSFEI is maintained | ||||
| 3.1.2 | Assessment of the draft EN with respect to this Standardization Request requirement | ||||
|
| This requirement has been fully met. For example, a trilateral meeting between the European Commission, the CEN TC 434 Management group and the activity leaders of the EMSFEI has been held to discuss policy aspects impacting the Draft EN. | ||||
Id | Standardization Request Item | Relevance | Risk | Conclusion | ||
3.2 | Standardization Request Text: | HIGH | LOW | MET | ||
| The standardization work shall take into account the documents to be used during the e-Procurement process, such as price list (or e-catalogue) and the associated orders, in order to have a rational and integrated approach. The possibility of allowing multilingualism and multicurrency usage shall also be taken into account. | |||||
| 3.2.1 | Discussion | ||||
|
| The requirement set out in the first sentence has been discussed above in section 2.10. Multilingualism and multicurrency are essential if the EN is to find adoption. | ||||
| 3.2.2 | Assessment of the draft EN with respect to this Standardization Request requirement | ||||
|
| Provisions for languages and currencies have been extensively discussed during the project and an appropriate rules-based approach included. | ||||
Id | Standardization Request Item | Relevance | Risk | Conclusion | ||
3.3 | Standardization Request Text: | MEDIUM | LOW | MET | ||
| Preservation of the existing investments made for e-invoicing implementation shall be ensured. The stability and the maintainability of the data model shall be considered at the same time. | |||||
| 3.3.1 | Discussion | ||||
|
| The requirement in the first sentence has been discussed in section 2.9 above, which also contains recommendations on usability. Stability and longevity of the model has been considered at all stages, and will be fully determined during the testing phase. | ||||
| 3.3.2 | Assessment of the draft EN with respect to this Standardization Request requirement | ||||
|
| This requirement is considered as met. | ||||
Id | Standardization Request Item | Relevance | Risk | Conclusion | ||
3.4 | Standardization Request Text: | MEDIUM | LOW | MET | ||
| All key stakeholders shall be directly represented in the work of the ESO (Project or Technical Committee, work groups, etc.) through National Standard Body delegations, ESOs Technical Committee and Workshop delegations, liaison partnerships, expert invitees, etc. | |||||
| 3.4.1 | Discussion | ||||
|
| In order to ensure that the ESO (European Standards Organization) work engages with all stakeholders the CEN/TC 434 Management Group should monitor the composition and contributions of its members. For example, were there sufficient contribution from contracting authorities, and the professionals who support the SME community? | ||||
| 3.4.2 | Assessment of the draft EN with respect to this Standardization Request requirement | ||||
|
| The composition of CEN/TC 434 was a matter for National Standards Organizations, which set out to ensure input from relevant stakeholders. A number of public sector representatives were either directly involved in the work of CEN/TC 434 or through national mirror committees. For SMEs it is always difficult to find direct participation, but a number of associations, governments and those already familiar with e-invoicing for the ‘long tail’ of suppliers were involved, either as NSO delegates or as liaison partners. | ||||
This is a Red, Amber, Green colour coding rating to indicate the level of importance to the EN design that the WS3 team have assigned to the requirements from the standardization. The intention was to provide the TC 434 semantic data model design team with a quick reference to help identify those requirements which are deemed to be of higher importance or relevance to the draft EN design. The colour coding is intended to indicate the following:
◄➔Low importance: Limited impact on draft EN design is expected.
◄➔Medium importance: Likely that there will be an impact on draft EN design.
◄➔High importance: Probable and essential that there will be an impact on the draft EN design.
This is a Red, Amber and Green colour coding to indicate an assessment of the risk that the requirement concerned might not be solved satisfactorily in the timescale available. Examples of factors involved are lack of expertise, lack of clarity, lack of consensus or complexity.
The intention is to provide the TC 434 semantic data model design team with a quick reference to help identify those requirements the delivery of which is deemed to be at higher risk. The colour coding is intended to indicate the following:
◄➔Low importance: resolution of issues at limited risk.
◄➔Medium importance: Possible there will be a risk of non-complete resolution.
◄➔High importance: Probable there will be a risk of non-complete resolution.
Directive 2014/55/EU [1] provides in its article 6, the base requirements in terms of groups of information that the core semantic data model details in the column marked ‘2014/55/EU [1]’ in the table below.
Directive 2014/55/EU [1] also mainly refers to other directives among which mainly 2006/112/EC [2] affects the content of the core Invoice:
— Directive 2006/112/EC [2], last version: 2006L0112 - EN - 01.01.2015 - 016.001;
The following requirements have been considered out of scope and so are not supported by the core invoice model:
— Article 223 about summary Invoices allowing referencing many deliveries;
— Article 224 and Article 226 10a about self-billing;
— Article 226 a and Article 226b about simplified Invoice.
Other requirements have been mapped to the elements in column 2006/112/EC amended by 2010/45/EC [2]:
— Directive 2011/7/EU [3] on combating late payment in commercial transactions requires a well identified recipient (See term Buyer electronic address).
ID | Business Term | Description | 2014/55/EU [1] | 2006/112/EC amended by 2010/45/EC |
BT-1 | Invoice number | A unique identification of the Invoice. | Art 6 a | Art 226 2 |
BT-2 | Invoice issue date | The date when the Invoice was issued. |
| Art 226 1 |
BT-5 | Invoice currency code | The currency in which all Invoice amounts are given, except for the Total VAT amount in accounting currency. | Art 6 l | Art 230 |
BT-6 | VAT accounting currency | The currency used for VAT accounting and reporting purposes as accepted or required in the country of the seller. |
| Art 230 |
BT-7 | Value added tax point date | The date when the VAT Becomes accountable for the Seller and for the Buyer in so far as that date can be determined and differs from the date of issue of the invoice. |
| Art 226 7 |
BT-8 | Value added tax point date code | The VAT point date according to Art. 63 - 67 |
| Art. 227 7a, |
BT-9 | Payment due date | The date when the payment is due. | 2011/7/EU [3] |
|
BT-12 | Contract identifier | The identification of a contract. | Art 6 g |
|
BT-20 | Payment terms | A textual description of the payment terms that apply to the amount due for payment (Including description of possible penalties). | 2011/7/EU [3] |
|
BG-2 | PROCESS CONTROL | A group of business terms providing information on the business process and rules applicable to the Invoice document. | Art 6 a |
|
BG-3 | PRECEDING INVOICE REFERENCE | A group of business terms providing information on one or more preceding Invoices. |
| Art 219 |
BG-4 | SELLER | A group of business terms providing information about the seller. | Art 6 c |
|
BT-27 | Seller name | The full formal name by which the Seller is registered in the national registry of legal entities or as a Taxable person or otherwise trades as a person or persons. |
| Art 226 5 |
BT-31 | Seller VAT identifier | The Seller's VAT identifier (also known as Seller VAT identification number). |
| Art 226 3 |
BT-32 | Seller tax registration | The local identification of the Seller for tax purposes or a reference that enables the Seller to state his registered tax status. |
| Art 239 |
BG-5 | SELLER POSTAL ADDRESS | A group of business terms providing information about the address of the Seller. |
| Art 226 5 |
BG-6 | SELLER CONTACT | A group of business terms providing contact information about the Seller. | Art 6 c |
|
BG-7 | BUYER | A group of business terms providing information about the Buyer. | Art 6 d |
|
BT-44 | Buyer name | The full name of the Buyer. |
| Art 226 5 |
BT-49 | Buyer electronic address | Identifies the Buyer's electronic address to which the invoice is delivered. | 2011/7/EU [3] |
|
BT-48 | Buyer VAT identifier | The Buyer's VAT identifier (also known as Buyer VAT identification number). |
| Art 226 4 |
BG-8 | BUYER POSTAL ADDRESS | A group of business terms providing information about the postal address for the Buyer. |
| Art 226 5 |
BG-9 | BUYER CONTACT | A group of business terms providing contact information relevant for the Buyer. | Art 6 d |
|
BG-10 | PAYEE | A group of business terms providing information about the payee, i.e. the role that receives the payment. | Art 6 e |
|
BG-11 | SELLER TAX REPRESENTATIVE PARTY | A group of business terms providing information about the Seller's tax representative. | Art 6 f | Art 226 15 |
BG-12 | SELLER TAX REPRESENTATIVE POSTAL ADDRESS | A group of business terms providing information about the postal address for the tax representative party. |
| Art 226 15 |
BG-13 | DELIVER TO INFORMATION | A group of business terms providing information about where and when the goods and services invoiced are delivered. | Art 6 h |
|
BG-14 | DELIVERY OR INVOICE PERIOD | A group of business terms providing information on the delivery or invoice period. | Art 6 b |
|
BG-15 | DELIVER TO ADDRESS | A group of business terms providing information about the address to which goods and services invoiced were or are delivered. | Art 6 h |
|
BG-16 | PAYMENT INSTRUCTIONS | A group of business terms providing information about the payment. | Art 6 i |
|
BG-17 | CREDIT TRANSFER | A group of business terms to specify credit transfer payments. | Art 6 i |
|
BG-18 | PAYMENT CARD INFORMATION | A group of business terms providing information about card used for payment contemporaneous with invoice issuance. | Art 6 i |
|
BG-20 | DOCUMENT LEVEL ALLOWANCES | A group of business terms providing information about allowances applicable to the Invoice as a whole. | Art 6 j |
|
BG-21 | DOCUMENT LEVEL CHARGES | A group of business terms providing information about charges and taxes other than VAT, applicable to the Invoice as a whole. | Art 6 j |
|
BG-22 | DOCUMENT TOTALS | A group of business terms providing the monetary totals for the Invoice. | Art 6 l |
|
BT-110 | Invoice total VAT amount | The total VAT amount for the Invoice. |
| Art 226 10 |
BT-111 | Invoice total VAT amount in accounting currency | The VAT total amount expressed in the accounting currency accepted or required in the country of the Seller. |
| Art 230 |
BT-115 | Amount due for payment | The outstanding amount that is requested to be paid. | 2011/7/EU [3] |
|
BG-23 | VAT BREAKDOWN | A group of business terms providing information about VAT breakdown by different categories, rates and exemption reasons | Art 6 m | Art 226 8 |
BT-119 | VAT category rate | The VAT rate, represented as percentage that applies for the relevant VAT category. |
| Art 226 9 |
BT-120 | VAT exemption / out of scope reason text | A textual statement of the reason why the amount is exempted from VAT or why no VAT is being charged |
| Art 226 11 to 14 |
BG-25 | INVOICE LINE | A group of business terms providing information on individual Invoice lines. | Art 6 k |
|
BG-26 | INVOICE LINE PERIOD | A group of business terms providing information about the Invoice period relevant for the Invoice line. | Art 6 b |
|
BG-27 | INVOICE LINE ALLOWANCES | A group of business terms providing information about allowances applicable to the individual Invoice line. | Art 6 j |
|
BG-28 | INVOICE LINE CHARGES | A group of business terms providing information about charges and taxes other than VAT applicable to the individual Invoice line. | Art 6 j |
|
BG-29 | PRICE DETAILS | A group of business terms providing information about the price applied for the goods and services invoiced on the Invoice line. | Art 6 k |
|
BG-30 | LINE VAT INFORMATION | A group of business terms providing information about the VAT applicable for the goods and services invoiced on the Invoice line. | Art 6 m | Art 226 8 |
BG-31 | ITEM INFORMATION | A group of business terms providing information about the goods and services invoiced. | Art 6 k |
|
BG-32 | ITEM ATTRIBUTES | A group of business terms providing information about properties of the goods and services invoiced. | Art 6 k |
|
BG-31 | ITEM INFORMATION | nature of the goods supplied or the extent and nature of the services rendered |
| Art. 226 (6) |
BT-153 | Item name |
|
|
|
BT-154 | Item description |
|
|
|
BT-155 | Item Seller's identifier |
|
|
|
BT-156 | Item Buyer's identifier |
|
|
|
BT-157 | Item standard identifier |
|
|
|
BT-158 | Item classification code |
|
|
|
BT-159 | Item country of origin |
|
|
|
The following symbols are used in the process diagrams. For a full explanation, see the Business Process Model and Notation (BPMN) specification [12].
— A Pool is the graphical representation of a Participant in a Collaboration. It also acts as a “swim lane” and a graphical container for partitioning a set of Activities from other Pools, usually in the context of B2B situations. | |
— A Lane is a sub-partition within a Process within a Pool, and will extend the entire length of the Process. Lanes are used to organize and categorize Activities. | |
— An Activity is a generic term for work that an organization performs in a Process. Activities are represented by rounded rectangles. | |
— A message is represented as an envelope. | |
— Circles represent events. An event that starts a process has a thin border; an event that ends a process has a thick border | |
— Diamond shapes represent gateways indicating the type of flow control behaviour. The types of control include: | |
— Message flows are indicated with a dotted arrow. | |
— Sequence flows are indicated with an arrow. | |
— Conversations (multiple communication flows that are not further detailed) are indicated with a double line. |
falseereffalse0false0false _id="b1"[1] Directive 2014/55/EU of the European Parliament and of The Council of 16 April 2014 on electronic invoicing in public procurement [viewed 2015-07-26] Available from http://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32014L0055.falseereffalse
falseereffalse0false0false _id="b2"[2] Council Directive. 2006/112/EC of 28 November 2006 on the common system of value added tax – last version: 2006L0112 - EN - 01.01.2015 - 016.001 [viewed 2015-07-26] Available from http://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02006L0112-20150101.falseereffalse
falseereffalse0false0false _id="b3"[3] Directive 2011/7/EU of the European Parliament and of the Council of 16 February 2011 on combating late payment in commercial transactions [viewed 2015-07-26] Available from http://eur-lex.europa.eu/legal-content/EN/ALL/?uri=CELEX:32011L0007.falseereffalse
falseereffalse0false0false _id="b4"[4] Directive 95/46/EC of the European Parliament and of the Council of 24 October 1995 on the protection of individuals with regard to the processing of personal data and on the free movement of such data [viewed 2015-07-26]. Available from http://eur-lex.europa.eu/legal-content/EN/TXT/?uri=URISERV:l14012.falseereffalse
falseereffalse0false0false _id="b5"[5] Council Directive. 2008/9/EC of 12 February 2008 laying down detailed rules for the refund of value added tax, provided for in Directive 2006/112/EC, to taxable persons not established in the Member State of refund but established in another Member State [viewed 2015-07-26]. Available from http://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32008L0009&qid=1437940645512.falseereffalse
falseereffalse0false0false _id="b6"[6] United Nations Trade Data Interchange Directory (UNTDID) http://www.unece.org/fileadmin/DAM/trade/untdid/d16b/tred/tredi2.htmfalseereffalse
falseereffalse0false0false _id="b7"[7] UN/ECE Recommendation N° 20 “Codes for Units of Measure Used in International Trade” [viewed 2015-07-26]. Available from http://www.unece.org/fileadmin/DAM/cefact/recommendations/rec20/rec20_ latest_08052015.zip.falseereffalse
falseereffalse0false0false _id="b8"[8] Regulation (EU) No 910/2014 of the European Parliament and of the Council of 23 July 2014 on electronic identification and trust services for electronic transactions in the internal market and repealing Directive 1999/93/EC [viewed 2015-07-26]. Available from http://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32014R0910.falseereffalse
falseereffalse0false0false _id="b9"[9] European Interoperability Framework (EIF) for European public services [viewed 2015-07-26]. Available from http://ec.europa.eu/isa/documents/isa_annex_ii_eif_en.pdf.falseereffalse
falseereffalse0false0false _id="b10"[10] Annex to the Commission Implementing Decision C. (2014)7912 final of 10 December 2014 on a standardisation request to the European standardisation organizations as regards a European standard on electronic invoicing and a set of ancillary standardisation deliverables pursuant to Regulation (EU) No 1025/2012 of the European Parliament and of the Council [viewed 2015-07-26]. Available from http://ec.europa.eu/DocsRoom/documents/8650/attachments/1/translations/en/renditions/pdf.falseereffalse
falseereffalse0false0false _id="b11"[11] Council Directive. 2008/118/EC concerning the general arrangements for excise duty and repealing Directive 92/12/EEC [viewed 2015-08-03]. Available from http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2009:009:0012:0030:EN:PDF.falseereffalse
falseereffalse0false0false _id="b12"[12] Object Management Group - Business Process Model and Notation v2, http://www.omg.org/spec/BPMN/2.0/falseereffalse
falseereffalse0false0false _id="b13"[13] SEPA Credit Transfer Scheme Implementation Guide http://www.europeanpaymentscouncil.eu/index.cfm/knowledge-bank/epc-documents/sepa-credit-transfer-scheme-customer-to-bank-implementation-guidelines-version-8/epc132-08-c2b-ctig-v80-approvedpdf/falseereffalse
falseereffalse0false0false _id="b14"[14] SEPA Direct Debit Scheme Implementation Guide http://www.europeanpaymentscouncil.eu/index.cfm/knowledge-bank/epc-documents/sepa-direct-debit-core-scheme-customer-to-bank-implementation-guidelines-version-8/epc130-08-sdd-core-c2b-ig-v80-approvedpdf/falseereffalse
falseereffalse0false0false _id="b15"[15] Clarification E.P.C. Paper on the Use of Slashes in References, Identifications and Identifiers http://www.europeanpaymentscouncil.eu/index.cfm/knowledge-bank/epc-documents/sepa-credit-transfer-scheme-customer-to-bank-implementation-guidelines-version-8/epc230-15-clarification-paper-on-the-use-of-slashes-in-references-identifications-and-identifierspdf/falseereffalse
falseereffalse0false0false _id="b16"[16] http://www.iso.org/iso/catalogue_detail.htm?csnumber=50649falseereffalse
falseereffalse0false0false _id="b17"[17] http://www.eact.eu/docs/EACT_Standard_for_Remittance_Info.pdffalseereffalse
falseereffalse0false0false _id="b18"[18] TOGAF architecture compliance. Available from http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap48.htmlfalseereffalse
falseereffalse0false0false _id="b19"[19] UN/ECE Recommendation N°. 21 - Codes for Passengers, Types of Cargo, Packages and Packaging Materials (with Complementary Codes for Package Names) http://www.unece.org/fileadmin/DAM/cefact/recommendations/rec21/rec21.zipfalseereffalse
falsestdfalse0false0false _id="b20"[20] ISO 639‑2, Codes for the representation of names of languages — Part 2: Alpha-3 codefalsestdfalse
1 In preparation.
2 http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=COM:2010:0712:FIN:en:PDF.
3 The suffix ".Type" has been deleted for readability.
4 http:// ec.europa.eu/idabc/servlets/Docb0db.pdf